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

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

Re: Spurious diagnostic messages

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

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 07:44 -0700
    Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-09-26 15:33 -0700
      Re: Spurious diagnostic messages Gareth Owen <gwowen@gmail.com> - 2015-09-28 19:57 +0100
        Re: Spurious diagnostic messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-09-28 20:52 +0100
        Re: Spurious diagnostic messages Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-09-29 11:19 +0000
      Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-09-28 22:26 +0000
        Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-09-30 13:56 +0100
          Re: Spurious diagnostic messages Gareth Owen <gwowen@gmail.com> - 2015-09-30 19:22 +0100
            Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-09-30 19:45 +0100
      Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 09:02 -0700
        Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-10-04 18:34 +0100
          Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-05 00:23 -0700
        Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-10-04 15:56 -0700
          Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-04 20:04 -0700
          Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-09 09:13 -0700
            Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-10-09 13:40 -0700
              Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-10 22:26 +0200
                Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-10 13:49 -0700
              Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-14 07:53 -0700
    Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-09-27 17:30 +1300
      Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 10:26 -0700
        Re: Spurious diagnostic messages Ian Collins <ian-news@hotmail.com> - 2015-10-05 17:02 +1300
          Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-09 10:06 -0700

Page 1 of 2  [1] 2  Next page →

#71218 — Re: Spurious diagnostic messages

Ian Collins <ian-news@hotmail.com> writes:

> Tim Rentsch wrote:
>> Ian Collins <ian-news@hotmail.com> writes:
>>
>>> Keith Thompson wrote:
>>>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>>>> On Fri, 31 Jul 2015 09:01:02 -0700, Keith Thompson <kst-u@mib.org>
>>>>> wrote:
>>>>
>>>> [...]
>>>>
>>>>>> As I mentioned earlier, if binary literals are added to C, I think
>>>>>> support should also be added to printf and scanf, probably using
>>>>>> "%b".  If this happens, C++ will eventually incorporate that feature
>>>>>> as part of the C standard library.  I suspect that would pressure
>>>>>> the C++ committee to add similar support to <iostream>.
>>>>>
>>>>> I disagree.  There's little requirement to input and output binary
>>>>> items.  Binary literals in a program, OTOH, are quite useful in some
>>>>> circumstances.
>>>>
>>>> We have decimal, octal, and hexadecimal constants, input, and output.
>>>> Having decimal, octal, hexadecimal, and binary constants, but only
>>>> decimal, octal, and hexadecimal input and output would be inconsistent.
>>>
>>> But that doesn't detract from the utility of binary constants.   As I
>>> said elsewhere, the use case for binary constants is primarily in the
>>> embedded world, stdio isn't a concern.
>>
>> And that's why it should be rejected.  Any language feature like
>> this one, that provides no capability beyond what is fairly
>> easily available otherwise, if not considered important to/by
>> the entire C development community, is not important enough
>> to add to the language.
>
> So all of the the maths stuff added to C99 was "considered important
> to/by the entire C development community"?  I've yet to meet anyone
> who would agree with that.  Look outside of your little box sometime
> and see what most C programmers are doing:  embedded code.

I'm sorry to be so long in responding here;  having to juggle too
many items.

An important phrase in what I said is "that provides no
capability beyond what is fairly easily available otherwise".
The math stuff doesn't fall into this category, whereas
binary constants do.

[toc] | [next] | [standalone]

#71235

Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]       
> An important phrase in what I said is "that provides no
> capability beyond what is fairly easily available otherwise".
> The math stuff doesn't fall into this category, whereas
> binary constants do.

You assert that binary constants don't provide a capability that
is fairly easily available othrwise.  I disagree.

The capability they provide is expressing bit patterns clearly.

It could be argued that hexadecimal constants provide the same
capabiility.  If I see `0x56`, it's obvious to me at a glance that
the bit pattern is `0b0101_0110` (I'll temporarily assume that we
have underscores in constants as well).  If I see `0xcd`, it takes
me a moment to figure out that the bit pattern is `0b1100_1101`.
That's just me, but I'm sure I'm not the only one.

If I want to *clearly* express a bit pattern as an integer, a binary
constant (if the language supports it) is in my opinion the best
and clearest way to do it.  If instead of `0b0101_0110`, I write
something like `BIN(01010110)` or `BIN("0101_0110")`, I first
have to be sure that the BIN() macro does what I think it does --
and I have to do that for each distinct implementation of such a
macro (likely with different names and different restrictions).
If a single consistent BIN macro can be propagated so it's used by
any code I'm likely to deal with, that's great -- but that's not
likely to happen unless it's in the standard.

A while ago you presented a macro that does something similar.
I don't remember just how you did it, and if I wanted to use it I'd
have to search for your article and copy the code.  (I recall it
being quite clever -- and that's both a good thing and a bad thing.)
Re-implementing it myself probably wouldn't be worth the effort;
I'd probably just use hex constants, perhaps with a comment to show
the bit pattern if needed.

I suspect that implementing binary constants in a compiler would
be *less* effort than re-implementing that macro.  For gcc in
particular, the effort would consist of disabling the warning that's
currently issued in pedantic mode and updating the documentation.
For compilers that don't already support binary constants, the
existing code that handles hex constants can be largely re-used.

-- 
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]

#71387

Keith Thompson <kst-u@mib.org> writes:

> If I see `0xcd`, it takes me a moment to figure out that the bit
> pattern is `0b1100_1101`.  That's just me, but I'm sure I'm not the
> only one.

It's not just you.

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

#71392

Gareth Owen <gwowen@gmail.com> writes:

> Keith Thompson <kst-u@mib.org> writes:
>
>> If I see `0xcd`, it takes me a moment to figure out that the bit
>> pattern is `0b1100_1101`.  That's just me, but I'm sure I'm not the
>> only one.
>
> It's not just you.

Indeed it isn't (i.e. me too) though I'm sure it depends, to a large
extent, on past experience.  In my case (to link this to another c.l.c
meme) I have immediate access to the bit pattern when I see 0315 where I
don't with 0xCD.

-- 
Ben.

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

#71424

On Mon, 2015-09-28, Gareth Owen wrote:
> Keith Thompson <kst-u@mib.org> writes:
>
>> If I see `0xcd`, it takes me a moment to figure out that the bit
>> pattern is `0b1100_1101`.  That's just me, but I'm sure I'm not the
>> only one.
>
> It's not just you.

I always keep a PostIT(tm) note on my screen which says

    8 .000 0
    9 .001 1
 a 10 .010 2
 b 11 .011 3
 c 12 .100 4
 d 13 .101 5
 e 14 .110 6
 f 15 .111 7

I don't know all of them by heart, and calculating them is
error-prone.  I don't want to introduce bugs because I'm too
proud to use a cheat sheet ...

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#71401

Keith Thompson <kst-u@mib.org> wrote:

(snip)
> You assert that binary constants don't provide a capability that
> is fairly easily available othrwise.  I disagree.
 
> The capability they provide is expressing bit patterns clearly.
 
> It could be argued that hexadecimal constants provide the same
> capabiility.  If I see `0x56`, it's obvious to me at a glance that
> the bit pattern is `0b0101_0110` (I'll temporarily assume that we
> have underscores in constants as well).  If I see `0xcd`, it takes
> me a moment to figure out that the bit pattern is `0b1100_1101`.
> That's just me, but I'm sure I'm not the only one.

As long as they are appropriately aligned, I can usually read them
fairly easily. (Not so long ago, I was doing microcode dumps reading
the lights in binary, and writing down hex digits. It takes me just
a little longer to distinguish X'B' and X'D'.)

By properly aligned, I mean that I can't do shifts that aren't
multiples of four in my head.  Reading a hex dump of IEEE floating
point values, and then putting the bits together before and after
the binary point, I have to write them down, then read back the
bits as new hex digits. 

Note the advantage for IBM hexadecimal floating point, where the
hexadecimal point is appropriately aligned in a hex dump.

-- glen

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

#71477

On 28/09/2015 23:26, glen herrmannsfeldt wrote:
> Keith Thompson <kst-u@mib.org> wrote:
>
> (snip)
>> You assert that binary constants don't provide a capability that
>> is fairly easily available othrwise.  I disagree.
>
>> The capability they provide is expressing bit patterns clearly.
>
>> It could be argued that hexadecimal constants provide the same
>> capabiility.  If I see `0x56`, it's obvious to me at a glance that
>> the bit pattern is `0b0101_0110` (I'll temporarily assume that we
>> have underscores in constants as well).  If I see `0xcd`, it takes
>> me a moment to figure out that the bit pattern is `0b1100_1101`.
>> That's just me, but I'm sure I'm not the only one.
>
> As long as they are appropriately aligned, I can usually read them
> fairly easily. (Not so long ago, I was doing microcode dumps reading
> the lights in binary, and writing down hex digits. It takes me just
> a little longer to distinguish X'B' and X'D'.)
>
> By properly aligned, I mean that I can't do shifts that aren't
> multiples of four in my head.  Reading a hex dump of IEEE floating
> point values, and then putting the bits together before and after
> the binary point, I have to write them down, then read back the
> bits as new hex digits.

This is it: binary is necessary going to be used in convenient 4-bit 
groups tidily aligned on 4-bit boundaries.

If looking for a non-aligned bit-pattern of ...01110... for example, 
that's always going to be easier with binary than hex or octal.

-- 
Bartc

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

#71492

Bartc <bc@freeuk.com> writes:

> This is it: binary is necessary going to be used in convenient 4-bit
> groups tidily aligned on 4-bit boundaries.

It is??? Your experience differs from mine, clearly.

> If looking for a non-aligned bit-pattern of ...01110... for example,
> that's always going to be easier with binary than hex or octal.

? Did you perhaps omit a *not* in the first sentence ?

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

#71494

On 30/09/2015 19:22, Gareth Owen wrote:
> Bartc <bc@freeuk.com> writes:
>
>> This is it: binary is necessary going to be used in convenient 4-bit
>> groups tidily aligned on 4-bit boundaries.
>
> It is??? Your experience differs from mine, clearly.
>
>> If looking for a non-aligned bit-pattern of ...01110... for example,
>> that's always going to be easier with binary than hex or octal.
>
> ? Did you perhaps omit a *not* in the first sentence ?

Yes. (Thunderbird doesn't seem to have a preview feature which other 
forums have - even Outlook Express had one, where many such typos can be 
picked up.)

My post should have read like this:

"This is it: binary isn't necessarily going to be used in convenient 
4-bit groups tidily aligned on 4-bit boundaries.

If looking for a non-aligned bit-pattern of ...01110... for example, 
that's always going to be easier with binary than hex or octal."

Anyway it should be clear from my previous posts in the thread that I'm 
for having binary literals and can't understand what the fuss is about 
from the one or two who don't want them in the language.)

-- 
Bartc

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

#71819

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
> [...]       
>> An important phrase in what I said is "that provides no
>> capability beyond what is fairly easily available otherwise".
>> The math stuff doesn't fall into this category, whereas
>> binary constants do.
>
> You assert that binary constants don't provide a capability that
> is fairly easily available othrwise.  I disagree.

If what we're talking about is being able to write an integer
constant in binary (aka base 2), the short macro definition I
posted recently demonstrates that this can be done in standard C,
without adding any new construct to the language.  Defining such
a macro can be done in a fairly obvious and straightforward way
(the one I posted was a little bit clever, but it doesn't have to
be that clever to be workable).  What part of this don't you
agree with?

> The capability they provide is expressing bit patterns clearly.
>
> It could be argued that hexadecimal constants provide the same
> capabiility.  If I see `0x56`, it's obvious to me at a glance that
> the bit pattern is `0b0101_0110` (I'll temporarily assume that we
> have underscores in constants as well).  If I see `0xcd`, it takes
> me a moment to figure out that the bit pattern is `0b1100_1101`.
> That's just me, but I'm sure I'm not the only one.
>
> If I want to *clearly* express a bit pattern as an integer, a binary
> constant (if the language supports it) is in my opinion the best
> and clearest way to do it.  If instead of `0b0101_0110`, I write
> something like `BIN(01010110)` or `BIN("0101_0110")`, I first
> have to be sure that the BIN() macro does what I think it does --
> and I have to do that for each distinct implementation of such a
> macro (likely with different names and different restrictions).
> If a single consistent BIN macro can be propagated so it's used by
> any code I'm likely to deal with, that's great -- but that's not
> likely to happen unless it's in the standard.
>
> A while ago you presented a macro that does something similar.
> I don't remember just how you did it, and if I wanted to use it I'd
> have to search for your article and copy the code.  (I recall it
> being quite clever -- and that's both a good thing and a bad thing.)
> Re-implementing it myself probably wouldn't be worth the effort;
> I'd probably just use hex constants, perhaps with a comment to show
> the bit pattern if needed.
>
> I suspect that implementing binary constants in a compiler would
> be *less* effort than re-implementing that macro.  For gcc in
> particular, the effort would consist of disabling the warning that's
> currently issued in pedantic mode and updating the documentation.
> For compilers that don't already support binary constants, the
> existing code that handles hex constants can be largely re-used.

What I think you're saying is that you would rather use binary
constants defined as a new language construct than one of the
other options (such as the macro alternative) now available in
standard C.  I accept that this is an accurate statement of
your preference, but it doesn't invalidate my assertion that
the ability to write constants in binary is fairly easily
available without having to add said construct to the language.
Do you agree with this?  Or have I misunderstood what you're
trying to say?

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

#71830

On 04/10/2015 17:02, Tim Rentsch wrote:
> Keith Thompson <kst-u@mib.org> writes:
>
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> [...]
>>> An important phrase in what I said is "that provides no
>>> capability beyond what is fairly easily available otherwise".
>>> The math stuff doesn't fall into this category, whereas
>>> binary constants do.
>>
>> You assert that binary constants don't provide a capability that
>> is fairly easily available othrwise.  I disagree.
>
> If what we're talking about is being able to write an integer
> constant in binary (aka base 2), the short macro definition I
> posted recently demonstrates that this can be done in standard C,
> without adding any new construct to the language.  Defining such
> a macro can be done in a fairly obvious and straightforward way
> (the one I posted was a little bit clever, but it doesn't have to
> be that clever to be workable).  What part of this don't you
> agree with?

There are some problems with using macros to represent binary literals. 
A few apply generally to trying to extend the language via macros, some 
Keith has already mentioned:

(1) You have to create the macro; but this is by no means as simple as
     you try to make out.

(2) You have to give it a name. Not hard, but see later points.

(3) Depending on how the macro is constructed, it might not scale
     easily to 16, 32 or 64 bits

(4) It might be awkward for a macro to accommodate arbitrary separators
     (which ought to be part of binary literals), or to do error-
     checking for illegal digits

(5) The macros have to be re-invented thousands of times over by
     different programmers (compared with once in a compiler).

(6) Each programmer is going to give them a slightly different name.
     They might also have different capabilities (eg some do separators,
     some don't).

(6) This can cause problems when sharing code, where someone is not
     familiar with a macro, or combining code involving two or more
     different, binary macros, or mixing with code that uses 0b...
     format.

(7) Sharing simple fragments of code, that would not otherwise rely on
     functions or macros, now have to drag a BIN macro around with them.

But the bottom line is this: if I have write a binary literal /right 
now/, then I can do it as fast as I can write if the language has them 
(and separators) built in.

It would take me appreciably longer to write a macro or to source a 
macro that would allow me to express this (for this example, the 
bit-pattern is significant and needs to easy to change):

   0b1_00_111_0000_11111_000000

-- 
Bartc

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

#71949

Bartc <bc@freeuk.com> writes:

> On 04/10/2015 17:02, Tim Rentsch wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> [...]
>>>> An important phrase in what I said is "that provides no
>>>> capability beyond what is fairly easily available otherwise".
>>>> The math stuff doesn't fall into this category, whereas
>>>> binary constants do.
>>>
>>> You assert that binary constants don't provide a capability that
>>> is fairly easily available othrwise.  I disagree.
>>
>> If what we're talking about is being able to write an integer
>> constant in binary (aka base 2), the short macro definition I
>> posted recently demonstrates that this can be done in standard C,
>> without adding any new construct to the language.  Defining such
>> a macro can be done in a fairly obvious and straightforward way
>> (the one I posted was a little bit clever, but it doesn't have to
>> be that clever to be workable).  What part of this don't you
>> agree with?
>
> There are some problems with using macros to represent binary
> literals.  A few apply generally to trying to extend the language via
> macros, some Keith has already mentioned:
>
> (1) You have to create the macro;  but this is by no means as simple as
>     you try to make out.
>
> (2) You have to give it a name.  Not hard, but see later points.
>
> (3) Depending on how the macro is constructed, it might not scale
>     easily to 16, 32 or 64 bits
>
> (4) It might be awkward for a macro to accommodate arbitrary separators
>     (which ought to be part of binary literals), or to do error-
>     checking for illegal digits
>
> (5) The macros have to be re-invented thousands of times over by
>     different programmers (compared with once in a compiler).
>
> (6) Each programmer is going to give them a slightly different name.
>     They might also have different capabilities (eg some do separators,
>     some don't).
>
> (6) This can cause problems when sharing code, where someone is not
>     familiar with a macro, or combining code involving two or more
>     different, binary macros, or mixing with code that uses 0b...
>     format.
>
> (7) Sharing simple fragments of code, that would not otherwise rely on
>     functions or macros, now have to drag a BIN macro around with them.
>
> But the bottom line is this:  if I have write a binary literal /right
> now/, then I can do it as fast as I can write if the language has them
> (and separators) built in.
>
> It would take me appreciably longer to write a macro or to source a
> macro that would allow me to express this (for this example, the
> bit-pattern is significant and needs to easy to change):
>
>   0b1_00_111_0000_11111_000000

None of these comments have a bearing on the point under
discussion, which is that binary constants can be accommodated in
regular C without needing a new language feature.

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

#71886

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> [...]       
>>> An important phrase in what I said is "that provides no
>>> capability beyond what is fairly easily available otherwise".
>>> The math stuff doesn't fall into this category, whereas
>>> binary constants do.
>>
>> You assert that binary constants don't provide a capability that
>> is fairly easily available othrwise.  I disagree.
>
> If what we're talking about is being able to write an integer
> constant in binary (aka base 2), the short macro definition I
> posted recently demonstrates that this can be done in standard C,
> without adding any new construct to the language.  Defining such
> a macro can be done in a fairly obvious and straightforward way
> (the one I posted was a little bit clever, but it doesn't have to
> be that clever to be workable).  What part of this don't you
> agree with?

I disagree that defining a macro that implements the equivalent of
binary constants is sufficiently obvious or straightforward.

Depending on how such a macro is defined, it might fail quietly if you
use it with the wrong number of digits.

If I'm reading code that uses such a macro, I have to spend time
understanding how the macro works.  If the code seems to be behaving
incorrectly, an incorrect macro definition is one more possible cause to
investigate.

Different programmers will define different macros.  Actually, most
programmers don't bother, because it's too much effort.  Providing
binary constants as a language feature solves both problems.

[...]

> What I think you're saying is that you would rather use binary
> constants defined as a new language construct than one of the
> other options (such as the macro alternative) now available in
> standard C.  I accept that this is an accurate statement of
> your preference, but it doesn't invalidate my assertion that
> the ability to write constants in binary is fairly easily
> available without having to add said construct to the language.
> Do you agree with this?  Or have I misunderstood what you're
> trying to say?

Pretty much, though I disagree that it's "fairly easy".  I find
that it's difficult enough that it's rarely worth the effort.

-- 
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]

#71923

On Sunday, October 4, 2015 at 5:56:40 PM UTC-5, Keith Thompson wrote:
> Different programmers will define different macros.  Actually, most
> programmers don't bother, because it's too much effort.  Providing
> binary constants as a language feature solves both problems.

Here I think is an important point: programmers outnumber compiler writers by
a considerable margin.  If even 10% of programmers would end up writing
code to do something, and an implementation of that functionality built into
the compiler would fit the needs of those programmers as well or better than
anything they could write themselves, having a few compiler writers implement
the feature would be a far better global use of manpower than having all of
the programmers who need that functionality write their own implementations.

In many situations where many programmers need largely similar functionality,
programmers' needs might be better met by their own implementations than by
compiler or standard-library implementations, and so the value of building
such functionality into the compiler or bundled library may be marginal.  On
the other hand, I would expect that compiler support for binary literals
could easily meet most programmers' needs as well as anything they could
write themselves, and thus I would consider that a very strong argument in
favor of standardizing such a thing.

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

#72271

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> [...]       
>>>> An important phrase in what I said is "that provides no
>>>> capability beyond what is fairly easily available otherwise".
>>>> The math stuff doesn't fall into this category, whereas
>>>> binary constants do.
>>>
>>> You assert that binary constants don't provide a capability that
>>> is fairly easily available othrwise.  I disagree.
>>
>> If what we're talking about is being able to write an integer
>> constant in binary (aka base 2), the short macro definition I
>> posted recently demonstrates that this can be done in standard C,
>> without adding any new construct to the language.  Defining such
>> a macro can be done in a fairly obvious and straightforward way
>> (the one I posted was a little bit clever, but it doesn't have to
>> be that clever to be workable).  What part of this don't you
>> agree with?
>
> I disagree that defining a macro that implements the equivalent of
> binary constants is sufficiently obvious or straightforward.

I think you may be responding to something that's different from
what I'm trying to say.  If I understand your comment, what
you're saying is like someone saying C should have an operator to
find the low-order 1 bit of an integer value, because they find
the C idiom to do that hard to understand.  But whether they
understand it or not, there is no question that the language as
it is provides a way to accomplish it.  My comment is about what
is fairly easily available as far as the /language/ is concerned,
not about what some (or many, or most) developers will think
about that.  The example macro definition uses straightforward C;
it doesn't rely on any odd corners of the language, or make use
of tortuous or contorted mechanisms.  (It does use a trick of
dividing by zero for digits that aren't zero or one, but that is
only to help detect errors, and moreover that general idea is a
widely understood one, showing up in various guises in static
assertion expressions.)  Do you see the distinction I'm trying to
identify?  When I say a capability is fairly easily available
otherwise, I mean the language provides a way to do it that
doesn't put too much strain on the language syntax and semantics.
IMO the macro definition I posted shows very little strain in how
it uses language syntax and semantics.  How it works might not be
obvious, but how it uses the C language is pretty straightforward.
Do you agree with that last statement?  If not can you say why?

> Depending on how such a macro is defined, it might fail quietly if
> you use it with the wrong number of digits.

Obviously that's true, but it doesn't affect the validity of my
statement.  Positing a poorly written macro is a strawman
argument.

> If I'm reading code that uses such a macro, I have to spend time
> understanding how the macro works.

Of course you don't, any more than you have to read compiler
code that would accept binary constants.  Normally one reads
documentation describing an interface, not implementation.
There is no reason a macro like this should be any different
in this regard.

> If the code seems to be behaving incorrectly, an incorrect macro
> definition is one more possible cause to investigate.

This is essentially the same strawman as above.  What you're
saying is that a macro _might_ not provide an acceptable
solution, not that it _could_ not provide an acceptable solution.
My comment is about what could be provided, not what might happen
in some hypothetical universe.  Talking about what might happen
gets us back to comparing the competing viewpoints, which is
a separate conversation.

> Different programmers will define different macros.  Actually, most
> programmers don't bother, because it's too much effort.  Providing
> binary constants as a language feature solves both problems.

Same comment as the last sentence above.

>> What I think you're saying is that you would rather use binary
>> constants defined as a new language construct than one of the
>> other options (such as the macro alternative) now available in
>> standard C.  I accept that this is an accurate statement of
>> your preference, but it doesn't invalidate my assertion that
>> the ability to write constants in binary is fairly easily
>> available without having to add said construct to the language.
>> Do you agree with this?  Or have I misunderstood what you're
>> trying to say?
>
> Pretty much, though I disagree that it's "fairly easy".  I find
> that it's difficult enough that it's rarely worth the effort.

The question I'm trying to address is Whether the language as it
is allows the construction of a means to accomplish what is
needed, in terms of the semantics of the operation provided.  I
believe the answer to that question is Yes.  I am specifically
not concerned (that is, for this subthread) with whether the
means to do that is desirable based on other criteria, or whether
it is better or worse than putting binary constants into the
language itself.  Do you see what I'm saying?

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

#72327

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
> The question I'm trying to address is Whether the language as it
> is allows the construction of a means to accomplish what is
> needed, in terms of the semantics of the operation provided.  I
> believe the answer to that question is Yes.  I am specifically
> not concerned (that is, for this subthread) with whether the
> means to do that is desirable based on other criteria, or whether
> it is better or worse than putting binary constants into the
> language itself.  Do you see what I'm saying?

Sure, it's possible to write a macro in current standard C that
provides something quite similar to binary constants.  I don't
recall ever claiming otherwise.

The issue for me (which may not be relevant to the point you're
making in this subthread) is that such a macro doesn't do me
any practical good, because I'm never going to bother to use it
in real-world code.  The cost of tracking down my saved copy of
your article, including it in my code, understanding the exact
characteristics of the macro (What's the type of the expression
it yields?  Does it expand to a constant expression?  Exactly what
does the argument need to look like?  What happens if I use an
incorrect argument?  Is all this stuff documented?), plus the cost
of any readers of my code figuring out what it means and trusting
that it works correctly, exceeds the cost of just using hex constants
rather than binary constants.

BTW, I'm sure the parenthesized questions above are answerable.
I'm not asking for answers, just that they're a cost I'd have to
incur before being willing to use your macro.

If binary constants were standard, all those costs would become
irrelevant.

Of course we don't *need* binary constants in C, but we don't *need*
hex constants or strlen() either.  If ISO never standardizes binary
constants, I probably won't even complain -- but I would prefer it
if they did.  (And if the committee requires a detailed cost-benefit
analysis, I'm perfectly content to sit back and let someone else
do it.)

-- 
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]

#72417

On 09/10/15 22:40, Keith Thompson wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
> [...]
>> The question I'm trying to address is Whether the language as it
>> is allows the construction of a means to accomplish what is
>> needed, in terms of the semantics of the operation provided.  I
>> believe the answer to that question is Yes.  I am specifically
>> not concerned (that is, for this subthread) with whether the
>> means to do that is desirable based on other criteria, or whether
>> it is better or worse than putting binary constants into the
>> language itself.  Do you see what I'm saying?
>
> Sure, it's possible to write a macro in current standard C that
> provides something quite similar to binary constants.  I don't
> recall ever claiming otherwise.
>
> The issue for me (which may not be relevant to the point you're
> making in this subthread) is that such a macro doesn't do me
> any practical good, because I'm never going to bother to use it
> in real-world code.  The cost of tracking down my saved copy of
> your article, including it in my code, understanding the exact
> characteristics of the macro (What's the type of the expression
> it yields?  Does it expand to a constant expression?  Exactly what
> does the argument need to look like?  What happens if I use an
> incorrect argument?  Is all this stuff documented?), plus the cost
> of any readers of my code figuring out what it means and trusting
> that it works correctly, exceeds the cost of just using hex constants
> rather than binary constants.

On the other hand, if you knew 0b binary literals were part of the 
standard, you'd just use them if you think a particular literal is 
clearer in binary.  That makes 0b literals arguably more useful to 
someone who doesn't do embedded programming on a regular basis - those 
whose code /really/ benefits from binary literals code spend the time 
making macros (and people have done that in the past, before 0b became 
common on most relevant compilers).

I'd just like to note, that as far as I remember Tim's macros, they 
don't actually cover the needs of binary literals (as well as being less 
convenient).  They would work in some situations, but not all.  Perhaps 
it would be possible to improve on them, but not without a good deal of 
effort.

>
> BTW, I'm sure the parenthesized questions above are answerable.
> I'm not asking for answers, just that they're a cost I'd have to
> incur before being willing to use your macro.
>
> If binary constants were standard, all those costs would become
> irrelevant.
>
> Of course we don't *need* binary constants in C, but we don't *need*
> hex constants or strlen() either.  If ISO never standardizes binary
> constants, I probably won't even complain -- but I would prefer it
> if they did.  (And if the committee requires a detailed cost-benefit
> analysis, I'm perfectly content to sit back and let someone else
> do it.)
>

The trouble is, if the committee insists on wanting a detailed 
cost-benefit analysis, people (compiler writers and compiler users) will 
say "sod that, I don't have time for such nonsense" because they already 
/have/ 0b binary literals.  And thus you get fragmentation because the 
committee has locked themselves in their ivory tower and is disconnected 
from what compiler writers and compiler users are actually doing.

And that is why, even though Tim makes a good point about wanting to 
know the benefits of a feature before it is added to the standards, he 
is still /wrong/ - because his attitude here is bad for C as a useful, 
practical, /living/ language.

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

#72419

On Saturday, October 10, 2015 at 3:26:49 PM UTC-5, David Brown wrote:
> And that is why, even though Tim makes a good point about wanting to 
> know the benefits of a feature before it is added to the standards, he 
> is still /wrong/ - because his attitude here is bad for C as a useful, 
> practical, /living/ language.

Certain aspects of the Committee behavior show contempt for the idea that
anyone would want a system with behavioral guarantees beyond what the
Committee sees fit to give them.

For example, from what I understand there was some discussion about changing
the behavior of (-1) << 1 from Undefined Behavior to Implementation-Defined
behavior, and it was shot down on the basis that it might impede certain
optimizations, despite the fact that there's a lot of code which relies upon
the behavior of that expression and is more readable than it would be if
it didn't, and despite the fact that opponents of the change were not able
to identify a single compiler were that expression did anything other than
yield a predictable value.

I can understand that there may be some ambiguity as to what value should
be yielded if code on a ones'-complement or sign-magnitude machine tries to
left-shift a negative value.  I see zero confusion about what should happen
on a two's-complement machine, and I know of no compilers for two's-
complement machines where the effect is anything other than a physical left
bit-shift.  Even though some platforms sometimes require an extra instruction
to ensure that left-shifting a negative number won't have any side-effects,
all compilers I know of for such platforms include that instruction.

Even though many compilers will peep-hole optimize x*=(1<<y); to eliminate the
multiply, I see nothing to be gained by requiring programmers of two's-
complement machines to use the latter form in preference to "x<<=y;" in
cases where x might be negative.  The refusal of the Committee to acknowledge
a behavior which has been common to EVERY SINGLE TWO'S COMPLEMENT COMPILER
shows a contempt for the language programmers actually want to use, and that
compiler vendors have historically given them.

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

#72841

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>
> [...]
>
>> The question I'm trying to address is Whether the language as it
>> is allows the construction of a means to accomplish what is
>> needed, in terms of the semantics of the operation provided.  I
>> believe the answer to that question is Yes.  I am specifically
>> not concerned (that is, for this subthread) with whether the
>> means to do that is desirable based on other criteria, or whether
>> it is better or worse than putting binary constants into the
>> language itself.  Do you see what I'm saying?
>
> Sure, it's possible to write a macro in current standard C that
> provides something quite similar to binary constants.  I don't
> recall ever claiming otherwise.

No, I didn't think you had.  I just wanted to be sure you
understood what it is I was trying to say.

> The issue for me (which may not be relevant to the point you're
> making in this subthread) is that such a macro doesn't do me
> any practical good, because I'm never going to bother to use it
> in real-world code.  [snip elaboration]

I believe I understand the position you're describing.  It seems
like the larger point has been lost, but since we each understand
what the other has been saying in this sub-thread, I will just
leave it at that for now.

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

#71253

Tim Rentsch wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>
>> Tim Rentsch wrote:
>>>
>>> And that's why it should be rejected.  Any language feature like
>>> this one, that provides no capability beyond what is fairly
>>> easily available otherwise, if not considered important to/by
>>> the entire C development community, is not important enough
>>> to add to the language.
>>
>> So all of the the maths stuff added to C99 was "considered important
>> to/by the entire C development community"?  I've yet to meet anyone
>> who would agree with that.  Look outside of your little box sometime
>> and see what most C programmers are doing:  embedded code.
>
> I'm sorry to be so long in responding here;  having to juggle too
> many items.

I thought you had taken offense at to being called a plutocrat :)

> An important phrase in what I said is "that provides no
> capability beyond what is fairly easily available otherwise".
> The math stuff doesn't fall into this category, whereas
> binary constants do.

As did a large part of the other additions in C99.  I would place binary 
constants in the same basket as stdint types and maybe bool.  No they 
don't provide a capability beyond what is fairly easily available 
otherwise but they do, through standardisation, make the programmer's 
job easier.  If anything, as simple typedefs stdint types were much more 
available than binary constants are today.

-- 
Ian Collins

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web