Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #59213 > unrolled thread

code for 32/64 bit strtoul strtol strtoull strtoll

Back to article view | Back to comp.lang.c

Contents

  code for 32/64 bit strtoul strtol strtoull strtoll jacob navia <jacob@jacob.remcomp.fr> - 2015-03-29 17:33 +0200
    code for 32/64 bit strtoul strtol strtoull strtoll asetofsymbols@gmail.com - 2015-03-29 09:22 -0700
      Re: code for 32/64 bit strtoul strtol strtoull strtoll Barry Schwarz <schwarzb@dqel.com> - 2015-03-29 15:12 -0700
        Re: code for 32/64 bit strtoul strtol strtoull strtoll asetofsymbols@gmail.com - 2015-03-29 23:07 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Barry Schwarz <schwarzb@dqel.com> - 2015-03-29 09:44 -0700
      Re: code for 32/64 bit strtoul strtol strtoull strtoll jacob navia <jacob@jacob.remcomp.fr> - 2015-03-29 19:05 +0200
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-29 12:15 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-30 02:01 +0100
      Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-29 19:48 -0700
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Barry Schwarz <schwarzb@dqel.com> - 2015-03-29 22:08 -0700
          Re: code for 32/64 bit strtoul strtol strtoull strtoll Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-30 12:44 +0100
            Re: code for 32/64 bit strtoul strtol strtoull strtoll Barry Schwarz <schwarzb@dqel.com> - 2015-03-30 09:04 -0700
              Re: code for 32/64 bit strtoul strtol strtoull strtoll Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-03-30 21:00 +0100
          Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-30 08:24 -0700
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 07:21 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Ian Collins <ian-news@hotmail.com> - 2015-03-30 18:02 +1300
      Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-03-30 08:03 +0100
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Ian Collins <ian-news@hotmail.com> - 2015-03-30 20:33 +1300
          Re: code for 32/64 bit strtoul strtol strtoull strtoll Ian Collins <ian-news@hotmail.com> - 2015-03-30 20:35 +1300
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Tim Rentsch <txr@alumni.caltech.edu> - 2015-03-30 07:27 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-30 09:08 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-30 09:29 -0700
    Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-03-30 15:16 -0500
      Re: code for 32/64 bit strtoul strtol strtoull strtoll jacob navia <jacob@jacob.remcomp.fr> - 2015-03-31 00:15 +0200
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-03-31 01:42 -0500
      Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-03-30 23:39 +0100
        Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-03-31 01:44 -0500
          Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-03-31 13:01 +0100
            Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-31 05:13 -0700
            Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-31 08:06 -0700
              Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-31 08:26 -0700
              Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-03-31 16:40 +0100
                Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-31 09:39 -0700
                Re: code for 32/64 bit strtoul strtol strtoull strtoll Kaz Kylheku <kaz@kylheku.com> - 2015-03-31 18:22 +0000
                  Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-03-31 19:36 +0100
                    Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-31 12:11 -0700
                    Re: code for 32/64 bit strtoul strtol strtoull strtoll Kaz Kylheku <kaz@kylheku.com> - 2015-03-31 19:23 +0000
              Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-03-31 16:52 +0100
                Re: code for 32/64 bit strtoul strtol strtoull strtoll glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-31 17:54 +0000
                  Re: code for 32/64 bit strtoul strtol strtoull strtoll raltbos@xs4all.nl (Richard Bos) - 2015-03-31 18:51 +0000
                    Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-03-31 20:05 +0100
                      Re: code for 32/64 bit strtoul strtol strtoull strtoll James Kuyper <jameskuyper@verizon.net> - 2015-03-31 15:18 -0400
                        Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-03-31 20:49 +0100
                          Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-31 13:06 -0700
                          Re: code for 32/64 bit strtoul strtol strtoull strtoll raltbos@xs4all.nl (Richard Bos) - 2015-04-06 13:03 +0000
                            Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-04-06 14:27 +0100
                            Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-04-06 17:01 +0100
                              Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-06 11:25 -0700
                              Re: code for 32/64 bit strtoul strtol strtoull strtoll James Kuyper <jameskuyper@verizon.net> - 2015-04-06 23:34 -0400
                                Re: code for 32/64 bit strtoul strtol strtoull strtoll glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-07 03:46 +0000
                                  Re: code for 32/64 bit strtoul strtol strtoull strtoll James Kuyper <jameskuyper@verizon.net> - 2015-04-08 11:05 -0400
                                    Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-08 08:31 -0700
                        Re: code for 32/64 bit strtoul strtol strtoull strtoll glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-03-31 19:54 +0000
                          Re: code for 32/64 bit strtoul strtol strtoull strtoll James Kuyper <jameskuyper@verizon.net> - 2015-03-31 16:55 -0400
                            Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-03-31 22:20 +0100
                            Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-31 14:36 -0700
                            Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-03-31 14:55 -0700
                              Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-03-31 17:00 -0700
                                Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-04-01 01:24 +0100
                                Re: code for 32/64 bit strtoul strtol strtoull strtoll James Kuyper <jameskuyper@verizon.net> - 2015-03-31 23:33 -0400
                                  Re: code for 32/64 bit strtoul strtol strtoull strtoll Richard Heathfield <rjh@cpax.org.uk> - 2015-04-01 04:42 +0100
                  Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-03-31 20:26 +0100
              Re: code for 32/64 bit strtoul strtol strtoull strtoll Ian Collins <ian-news@hotmail.com> - 2015-04-01 10:33 +1300
                Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-04-01 04:33 -0500
                  Re: code for 32/64 bit strtoul strtol strtoull strtoll Bartc <bc@freeuk.com> - 2015-04-01 12:43 +0100
                    Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-04-02 01:02 -0500
                      Re: code for 32/64 bit strtoul strtol strtoull strtoll asetofsymbols@gmail.com - 2015-04-01 23:57 -0700
                        Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-04-03 00:29 -0500
                      Re: code for 32/64 bit strtoul strtol strtoull strtoll Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-04-02 09:01 -0700
                        Re: code for 32/64 bit strtoul strtol strtoull strtoll Keith Thompson <kst-u@mib.org> - 2015-04-02 14:30 -0700
                        Re: code for 32/64 bit strtoul strtol strtoull strtoll Robert Wessel <robertwessel2@yahoo.com> - 2015-04-03 00:39 -0500
                  Re: code for 32/64 bit strtoul strtol strtoull strtoll glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-04-01 15:55 +0000

Page 4 of 4 — ← Prev page 1 2 3 [4]

#59374

On 01/04/15 04:33, James Kuyper wrote:

<snip>

> read about it in connection with a virus which was carried around in a
> structure that was made of a fixed and relatively small number of
> protein units arranged in a strict geometric shape. The central part
> looked like a geodesic dome, plus there were "legs" and an an injector
> that was used to penetrate cell walls.

This sounds very much like the T4 phage.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

[toc] | [prev] | [next] | [standalone]

#59359

On 31/03/2015 18:54, glen herrmannsfeldt wrote:
> Bartc <bc@freeuk.com> wrote:
>
> (snip)
>
>> I meant 2, 8, 10 and 16, which are in the range 2 to 16. Although I did
>> make use of base 4 the other week (meaning I use base 4 more than base 8).
>
> There is a lot of work done in base 4, if you use A, C, T, and G
> instead of 0, 1, 2, 3 for the digits.

Being able to read or print int values from or to a quaternary text 
representation is useful, but what is more apt is an actual packed bit 
or 2-bit type especially when you need a lot of such digits as you would 
for ACGT sequences.

(As it happens, I have a language that allows exactly that. A 400M array 
of 2-bit values occupies 100MB, and when printed looks like: 
(3,1,1,0,2,2,...) with values in base 10!)

However, my use of it was like you suggest, to easily represent 2-bit 
data within a normal int constant, something like this:

((4x32323_32323_030 >> (x*2)) & 3) + 28

(which converts month x, 1 to 12, into the number of days in the month, 
excluding leap years. The 3, 2, 0 digits are deviations from 28 days.)

This would be a harmless little extension to any language including C, 
and has virtually zero implementation cost.

(Bit types, in the form of bit-arrays and bit-pointers, are also useful, 
but are not such a trivial addition to the language.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#59365

Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:
>> On 31/03/2015 07:44, Robert Wessel wrote:
> [...]
>>> The base may be any (integer) value 2..36.
>>
>> Sounds like ridiculous over-specification to me, because if you're
>> going to allow base 36, why not 136? Bases in the range 2 to 16 are
>> very common and useful; above 16 aren't.
>
> Base 7 is common and useful?
>
> Bases up to 36 are permitted because the digits can be represented
> straightforwardly using decimal digits and letters.  Restricting the
> base to, say, 2, 8, 10, or 16 (or 0) would have been arbitrary;
> permitting any base from 2 to 36 would not make the implementation
> significantly easier.  (And base 36 might be an almost reasonable
> way to represent numbers compactly, though it's not particularly
> human-readable.)

I have encountered one real example of using higher bases to represent 
numbers compactly which was a message number in a test based comms protocol.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#59386

On Wed, 01 Apr 2015 10:33:33 +1300, Ian Collins <ian-news@hotmail.com>
wrote:

>Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>>> On 31/03/2015 07:44, Robert Wessel wrote:
>> [...]
>>>> The base may be any (integer) value 2..36.
>>>
>>> Sounds like ridiculous over-specification to me, because if you're
>>> going to allow base 36, why not 136? Bases in the range 2 to 16 are
>>> very common and useful; above 16 aren't.
>>
>> Base 7 is common and useful?
>>
>> Bases up to 36 are permitted because the digits can be represented
>> straightforwardly using decimal digits and letters.  Restricting the
>> base to, say, 2, 8, 10, or 16 (or 0) would have been arbitrary;
>> permitting any base from 2 to 36 would not make the implementation
>> significantly easier.  (And base 36 might be an almost reasonable
>> way to represent numbers compactly, though it's not particularly
>> human-readable.)
>
>I have encountered one real example of using higher bases to represent 
>numbers compactly which was a message number in a test based comms protocol.


I've seen a few cases of encoding a serial/id number to shorten it.
Dell's service tag, on each of their PCs, for example, is a base-36
number (approximately - I don't know if they've eliminated any digit
pairs like 0/O).  IBM invoice numbers were a base-36 (again,
approximately) number for decades, although they appear to have
changed that in the last decade or so.

[toc] | [prev] | [next] | [standalone]

#59392

On 01/04/2015 10:33, Robert Wessel wrote:
> On Wed, 01 Apr 2015 10:33:33 +1300, Ian Collins <ian-news@hotmail.com>
> wrote:
>
>> Keith Thompson wrote:
>>> Bartc <bc@freeuk.com> writes:
>>>> On 31/03/2015 07:44, Robert Wessel wrote:
>>> [...]
>>>>> The base may be any (integer) value 2..36.
>>>>
>>>> Sounds like ridiculous over-specification to me, because if you're
>>>> going to allow base 36, why not 136? Bases in the range 2 to 16 are
>>>> very common and useful; above 16 aren't.
>>>
>>> Base 7 is common and useful?
>>>
>>> Bases up to 36 are permitted because the digits can be represented
>>> straightforwardly using decimal digits and letters.  Restricting the
>>> base to, say, 2, 8, 10, or 16 (or 0) would have been arbitrary;
>>> permitting any base from 2 to 36 would not make the implementation
>>> significantly easier.  (And base 36 might be an almost reasonable
>>> way to represent numbers compactly, though it's not particularly
>>> human-readable.)
>>
>> I have encountered one real example of using higher bases to represent
>> numbers compactly which was a message number in a test based comms protocol.
>
>
> I've seen a few cases of encoding a serial/id number to shorten it.
> Dell's service tag, on each of their PCs, for example, is a base-36
> number (approximately - I don't know if they've eliminated any digit
> pairs like 0/O).  IBM invoice numbers were a base-36 (again,
> approximately) number for decades, although they appear to have
> changed that in the last decade or so.
>

OK, I'll go along with that then.

For a bit of fun here's a string-to-int function that can work with 
bases beyond 36, and will work for any length of input so overflow is 
not an issue. The example given is in base-60 with "O" and "o" excluded. 
(http://pastebin.com/b6nE6Ygb *Not in C* otherwise it would have taken a 
week instead of a few minutes.)

My point is that these uses are specialised and don't really belong in 
the language. Not when C hardly has base-2 input and output yet!

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#59420

On Wed, 01 Apr 2015 12:43:32 +0100, Bartc <bc@freeuk.com> wrote:

>On 01/04/2015 10:33, Robert Wessel wrote:
>> On Wed, 01 Apr 2015 10:33:33 +1300, Ian Collins <ian-news@hotmail.com>
>> wrote:
>>
>>> Keith Thompson wrote:
>>>> Bartc <bc@freeuk.com> writes:
>>>>> On 31/03/2015 07:44, Robert Wessel wrote:
>>>> [...]
>>>>>> The base may be any (integer) value 2..36.
>>>>>
>>>>> Sounds like ridiculous over-specification to me, because if you're
>>>>> going to allow base 36, why not 136? Bases in the range 2 to 16 are
>>>>> very common and useful; above 16 aren't.
>>>>
>>>> Base 7 is common and useful?
>>>>
>>>> Bases up to 36 are permitted because the digits can be represented
>>>> straightforwardly using decimal digits and letters.  Restricting the
>>>> base to, say, 2, 8, 10, or 16 (or 0) would have been arbitrary;
>>>> permitting any base from 2 to 36 would not make the implementation
>>>> significantly easier.  (And base 36 might be an almost reasonable
>>>> way to represent numbers compactly, though it's not particularly
>>>> human-readable.)
>>>
>>> I have encountered one real example of using higher bases to represent
>>> numbers compactly which was a message number in a test based comms protocol.
>>
>>
>> I've seen a few cases of encoding a serial/id number to shorten it.
>> Dell's service tag, on each of their PCs, for example, is a base-36
>> number (approximately - I don't know if they've eliminated any digit
>> pairs like 0/O).  IBM invoice numbers were a base-36 (again,
>> approximately) number for decades, although they appear to have
>> changed that in the last decade or so.
>>
>
>OK, I'll go along with that then.
>
>For a bit of fun here's a string-to-int function that can work with 
>bases beyond 36, and will work for any length of input so overflow is 
>not an issue. The example given is in base-60 with "O" and "o" excluded. 
>(http://pastebin.com/b6nE6Ygb *Not in C* otherwise it would have taken a 
>week instead of a few minutes.)
>
>My point is that these uses are specialised and don't really belong in 
>the language. Not when C hardly has base-2 input and output yet!


I'm not really defending the way the strto*() functions are designed,
but given what they do allowing any integer base 2-36 is really only a
tiny bit of overdesign compared to allowing only a few bases in that
range.  The complexity in the implementation of those functions is
clearly *not* in the bit where the string of digits is interpreted. So
it might be a bit odd, but it's pretty much a non-issue.

In general C's input an output functions have many limitations and
quirks, the input functions being almost unusable. At least if the
format parsed by strto*() is the one you want, you can actually use
those functions in code having to deal with real-world inputs, which
is more than you can say for anything in the scanf family.

While I've rarely needed to support binary input, I've certainly
really wanted binary literals more than once.

[toc] | [prev] | [next] | [standalone]

#59421

I not understand how can be
-2345
can be ok as input for one unsigned

user!=programmer

And even if it be one programmer
 how one can know
for sure -2345 is converted
to the right unsigned number?

[toc] | [prev] | [next] | [standalone]

#59501

On Wed, 1 Apr 2015 23:57:30 -0700 (PDT), asetofsymbols@gmail.com
wrote:


This is Usenet.  Please quote properly.


>I not understand how can be
>-2345
>can be ok as input for one unsigned
>
>user!=programmer


I agree, what strto*() will accept is very often not what the spec
says to accept.  In fact what those functions accept is pretty weird
in many cases, certainly for non-programmers, and probably even for
non-C programmers.  My point was that unlike many of the other C input
function, you can actually use the strto*() functions should your
input requirements match what those functions do.

If you're willing to limit the input to the range 0..((2**31)-1)
(assuming a 32-bit conversion), you can use the signed conversion
functions, and check for a negative input.  You still might be
accepting odd prefixes and suffices that you might care to generally
disallow for your application.


>And even if it be one programmer
> how one can know
>for sure -2345 is converted
>to the right unsigned number?


The "right" unsigned number is going to be generated using the normal
conversion and unsigned math rules.  Whether that's the behavior you
want is a different question.

[toc] | [prev] | [next] | [standalone]

#59462

On Thursday, April 2, 2015 at 7:01:14 AM UTC+1, robert...@yahoo.com wrote:
>
> In general C's input an output functions have many limitations and
> quirks, the input functions being almost unusable. At least if the
> format parsed by strto*() is the one you want, you can actually use
> those functions in code having to deal with real-world inputs, which
> is more than you can say for anything in the scanf family.
>
The printf() format string has been  big hit, imitated by numerous other languages.
However it doesn't adapt well to Russian doll programming, because you need to 
know the width of the integers you a re passing to it. So if we invent a new type,call 
it index_t, we can't print out an index_t without casting it to something else, 
which defeats the purpose of having an index_t.

The input functions are showing their age. They're Ok for low security input of
automatically generated file, but issues such as how to represent missing data,
Nans, signed zeros, infinities and infinitesimals, and so on aren't nailed down,
mean that it's hard to make them really solid. There's also the irritating rule that
newline doesn't match a newline in scant() 

[toc] | [prev] | [next] | [standalone]

#59493

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Thursday, April 2, 2015 at 7:01:14 AM UTC+1, robert...@yahoo.com wrote:
>> In general C's input an output functions have many limitations and
>> quirks, the input functions being almost unusable. At least if the
>> format parsed by strto*() is the one you want, you can actually use
>> those functions in code having to deal with real-world inputs, which
>> is more than you can say for anything in the scanf family.
>>
> The printf() format string has been  big hit, imitated by numerous other languages.
> However it doesn't adapt well to Russian doll programming, because you need to 
> know the width of the integers you a re passing to it. So if we invent a new type,call 
> it index_t, we can't print out an index_t without casting it to something else, 

Yes.

> which defeats the purpose of having an index_t.

No.

You only have to do the cast when passing an index_t value to printf(),
which typically will not be a common occurrence.  Assuming index_t is an
integer type, and assuming it's signed, you can just do:

    index_t index = ...;
    printf("%jd", (intmax_t)index);

It gets slightly more complicated if you don't know the signedness of
index_t, or if you can't assume C99 support, but that can be handled.

Output code like that is typically isolated; most code that deals
with index_t objects and values doesn't have to worry about it.

Whatever purpose there is to having a distinct index_t type is not
defeated by the minor inconvenience of not having a printf format for
it.

It Would Be Nice to have type-safe output where you don't have to know
the type of something to be able to print it.  (C++'s std::cout << ...
has its advantages, but one big problem IMHO is that changing an output
format changes the state of the output stream.)

There are some things you can do with _Generic, but it's less convenient
than actual overloading.  (I express no opinion at this time on whether
adding overloading to C would be a good or bad idea.)

> The input functions are showing their age. They're Ok for low security input of
> automatically generated file, but issues such as how to represent missing data,
> Nans, signed zeros, infinities and infinitesimals, and so on aren't nailed down,
> mean that it's hard to make them really solid. There's also the irritating rule that
> newline doesn't match a newline in scant() 

Yes, input is messy.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#59502

On Thu, 2 Apr 2015 09:01:29 -0700 (PDT), Malcolm McLean
<malcolm.mclean5@btinternet.com> wrote:

>On Thursday, April 2, 2015 at 7:01:14 AM UTC+1, robert...@yahoo.com wrote:
>>
>> In general C's input an output functions have many limitations and
>> quirks, the input functions being almost unusable. At least if the
>> format parsed by strto*() is the one you want, you can actually use
>> those functions in code having to deal with real-world inputs, which
>> is more than you can say for anything in the scanf family.
>>
>The printf() format string has been  big hit, imitated by numerous other languages.
>However it doesn't adapt well to Russian doll programming, because you need to 
>know the width of the integers you a re passing to it. So if we invent a new type,call 
>it index_t, we can't print out an index_t without casting it to something else, 
>which defeats the purpose of having an index_t.


Certainly for the cases printf() handles, it's fairly successful.  But
you can pretty quickly hit the limits if you have some new type, want
custom formatting (I'd like thousands separators* or right alignment
in my numbers, please), or have to deal with internationalization.


*They didn't add the ' modifier to C11, did they?


>The input functions are showing their age. They're Ok for low security input of
>automatically generated file, but issues such as how to represent missing data,
>Nans, signed zeros, infinities and infinitesimals, and so on aren't nailed down,
>mean that it's hard to make them really solid. There's also the irritating rule that
>newline doesn't match a newline in scant() 


I'm pretty much of the opinion that in 2015 there are essentially no
cases where you can't assume malicious input.  And even if you have a
fairly well trusted machine source, the inability to produce some sort
of descent diagnostic when the input does get mangled in some way is a
major impediment to debugging the problem.  Nor do most machine
sources by default produce something you can parse with scanf().

The input functions do serve a pedagogical purpose, where confusing
the students with the complexities of dealing with real input would be
counterproductive.

[toc] | [prev] | [next] | [standalone]

#59406

Robert Wessel <robertwessel2@yahoo.com> wrote:

(snip)

> I've seen a few cases of encoding a serial/id number to shorten it.
> Dell's service tag, on each of their PCs, for example, is a base-36
> number (approximately - I don't know if they've eliminated any digit
> pairs like 0/O).  IBM invoice numbers were a base-36 (again,
> approximately) number for decades, although they appear to have
> changed that in the last decade or so.

IBM S/370 (and later) serial numbers are base 16. That is important is
the (privileged) STIDP instruction will return it. 

-- glen

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

Back to top | Article view | comp.lang.c

csiph-web