Deutsch   English   Français   Italiano  
<86r0cmgb96.fsf@linuxsc.com>

View for Bookmarking (what is this?)
Look up another Usenet article

Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: The difference between strtol() and strtoul() ?
Date: Sun, 23 Jun 2024 22:28:37 -0700
Organization: A noiseless patient Spider
Lines: 27
Message-ID: <86r0cmgb96.fsf@linuxsc.com>
References: <v51d1l$2fklr$1@news.xmission.com> <v540t9$2gsdu$1@news.xmission.com> <20240621182839.00000dc4@yahoo.com> <20240621185314.00004fda@yahoo.com> <87o77uqktg.fsf@bsb.me.uk> <20240623121952.00005fa9@yahoo.com> <87r0cnq46s.fsf@bsb.me.uk> <20240623153219.000009b0@yahoo.com> <87jzifpth6.fsf@bsb.me.uk> <864j9jh77d.fsf@linuxsc.com> <Xj0eO.6172$ZwRb.2109@fx38.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Mon, 24 Jun 2024 07:28:38 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b3b1304951eae8dc1e53ef86c96f1e35";
	logging-data="841669"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19iiOJA1Bj/so5FMURkNeq0pByMVrcC7fw="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:WYyz7aAs5Go0X+4cmolrzO0DzwU=
	sha1:bDOlcQW/uKj042vx8W0SuTq6rho=
Bytes: 2538

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Ben Bacarisse <ben@bsb.me.uk> writes:
>>
>> [range questions for strtol(), etc]
>>
>>> I think there /is/ something problematic with the wording about the
>>> negation.  It happens "in the return type" but how can
>>> 9223372036854775808 be negated in the type long long int?  OK, the
>>> negated value can be /represented/ in the type long long int but that's
>>> not quite the same thing.  On the othee hand, for the unsigned return
>>> types, the negation "in the return type" is what produces ULONG_MAX for
>>> "-1" when the negated value, -1, can't be /represented/ in the return
>>> type.  It's a case where, over the years, I've just got used to what's
>>> happening.
>>
>> I understand what these functions do, but their specification in the
>> C standard is a little off.  To my way of thinking the impact is
>> minimal, but the specified behavior is either unequivocally wrong or
>> there are some cases that give rise to undefined behavior.
>
> I think you're both overthinking it.

You aren't saying anything.  Do you have something to
say that actually has positive information content?