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

Groups > comp.lang.c > #71431 > 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-29 08:55 -0700
    Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-09-29 10:22 -0700
      Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 23:42 -0700
        Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-05 09:41 -0700
          Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-09 13:22 -0700
    Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-09-29 22:28 +0200
      Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-05 00:14 -0700
        Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-05 10:30 +0200
          Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-05 10:06 -0700
            Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-06 09:23 +0200
              Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-06 11:18 -0700
                Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-10-06 14:29 -0700
                  Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-06 15:33 -0700
                  Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-07 12:35 +0200
                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-07 10:57 +0200
                  Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-07 07:09 -0700
                    Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-08 09:28 +0200
                      Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-08 01:45 -0700
                        Re: Spurious diagnostic messages glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-08 09:42 +0000
                          Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-08 09:42 -0700
                  Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-10-07 09:40 -0700
                    Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-08 09:44 +0200
                      Re: Spurious diagnostic messages Keith Thompson <kst-u@mib.org> - 2015-10-08 08:25 -0700
                        Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-08 20:36 +0200
                          Re: Spurious diagnostic messages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-08 13:28 -0700
                            Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-10-08 22:21 +0100
                              Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-08 14:33 -0700
                            Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-09 10:24 +0200
                              Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-09 08:35 -0700
                                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-11 15:18 +0200
                                  Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-11 14:53 -0700
                                    Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-12 09:17 +0200
                                      Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-12 00:37 -0700
                              Re: Spurious diagnostic messages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-10 00:31 -0700
                                Re: Spurious diagnostic messages Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-10 10:50 +0100
                                Re: Spurious diagnostic messages Bartc <bc@freeuk.com> - 2015-10-10 11:01 +0100
                                  Re: Spurious diagnostic messages Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-10 03:43 -0700
                                    Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-10 13:26 -0700
                                    Re: Spurious diagnostic messages supercat@casperkitty.com - 2015-10-10 13:34 -0700
                                Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-11 15:25 +0200
          Re: Spurious diagnostic messages Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-14 07:43 -0700
            Re: Spurious diagnostic messages David Brown <david.brown@hesbynett.no> - 2015-10-14 17:00 +0200

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#72141

David Brown <david.brown@hesbynett.no> writes:
[...]
> /I/ see no problem with just adding 0b binary literals to the standard
> for the next version of C.  But I understand that other people /do/ see
> it as a problem.

Has more than one person here (Tim Rentsch) expressed opposition to
adding 0b binary literals to the standard?  (I'm not trying to suggest
that Tim's objections are invalid because he's the only one offering
them.)

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

#72184

On 07/10/15 18:40, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> /I/ see no problem with just adding 0b binary literals to the standard
>> for the next version of C.  But I understand that other people /do/ see
>> it as a problem.
> 
> Has more than one person here (Tim Rentsch) expressed opposition to
> adding 0b binary literals to the standard?  (I'm not trying to suggest
> that Tim's objections are invalid because he's the only one offering
> them.)
> 

Tim is the only one I can think of, but there may be others.  And I
believe the C standards committee has already rejected one attempt at
adding 0b binary literals, with arguments not unlike Tim's.  So either
Tim is behind that rejection, or there is at least one other person
around who doesn't like them!

(I accept that Tim has valid objections - I just don't think they are as
important as he does, and I don't think they outweigh the benefits of 0b
literals as I see them.)

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

#72197

David Brown <david.brown@hesbynett.no> writes:
> On 07/10/15 18:40, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> /I/ see no problem with just adding 0b binary literals to the standard
>>> for the next version of C.  But I understand that other people /do/ see
>>> it as a problem.
>> 
>> Has more than one person here (Tim Rentsch) expressed opposition to
>> adding 0b binary literals to the standard?  (I'm not trying to suggest
>> that Tim's objections are invalid because he's the only one offering
>> them.)
>
> Tim is the only one I can think of, but there may be others.  And I
> believe the C standards committee has already rejected one attempt at
> adding 0b binary literals, with arguments not unlike Tim's.  So either
> Tim is behind that rejection, or there is at least one other person
> around who doesn't like them!

I just took a quick look at the DRs for C90, C99, and C11 (searching for
"binary", "0b", and "base"), and I didn't see any such proposal.

The DRs can be seen at:

C90: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr.htm
C99: http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary-c99.htm
C11: http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm

> (I accept that Tim has valid objections - I just don't think they are as
> important as he does, and I don't think they outweigh the benefits of 0b
> literals as I see them.)

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

#72209

On 08/10/15 17:25, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 07/10/15 18:40, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>> [...]
>>>> /I/ see no problem with just adding 0b binary literals to the standard
>>>> for the next version of C.  But I understand that other people /do/ see
>>>> it as a problem.
>>>
>>> Has more than one person here (Tim Rentsch) expressed opposition to
>>> adding 0b binary literals to the standard?  (I'm not trying to suggest
>>> that Tim's objections are invalid because he's the only one offering
>>> them.)
>>
>> Tim is the only one I can think of, but there may be others.  And I
>> believe the C standards committee has already rejected one attempt at
>> adding 0b binary literals, with arguments not unlike Tim's.  So either
>> Tim is behind that rejection, or there is at least one other person
>> around who doesn't like them!
>
> I just took a quick look at the DRs for C90, C99, and C11 (searching for
> "binary", "0b", and "base"), and I didn't see any such proposal.
>
> The DRs can be seen at:
>
> C90: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr.htm
> C99: http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary-c99.htm
> C11: http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm

 From 
<http://stackoverflow.com/questions/18244726/why-doesnt-c-have-binary-literals>

	According to Rationale for International Standard - Programming 
Languages C 
<http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf>

§6.4.4.1 Integer constants

     A proposal to add binary constants was rejected due to lack of 
precedent and insufficient utility.



I'm fairly sure I read another similar reference somewhere, but I can't 
find that any more.  It may be that the suggestion did not reach far 
enough in the formal processes to end up on the lists you have 
referenced - I don't know how the system works.

But it would be hard to believe that the suggestion has not been made to 
include binary literals in future C standards, and since there is no 
problem with precedent or implementation (at least, not now - there may 
have been few implementations before C99 was written), it seems 
reasonable to suspect that it has been rejected for similar reasons to 
Tim's - that few people need them, and there are existing ways to get a 
similar effect without changing the language.

>
>> (I accept that Tim has valid objections - I just don't think they are as
>> important as he does, and I don't think they outweigh the benefits of 0b
>> literals as I see them.)
>

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

#72214

On Thursday, October 8, 2015 at 7:36:17 PM UTC+1, David Brown wrote:
> On 08/10/15 17:25, Keith Thompson wrote:
> 
> But it would be hard to believe that the suggestion has not been made to 
> include binary literals in future C standards, and since there is no 
> problem with precedent or implementation (at least, not now - there may 
> have been few implementations before C99 was written), it seems 
> reasonable to suspect that it has been rejected for similar reasons to 
> Tim's - that few people need them, and there are existing ways to get a 
> similar effect without changing the language.
> 
I can't really think of a use other than low end bit-mapped,
character cell-based graphics. But whilst the binary literal
will allow you to see the bit pattern, editing 8x8s by hand is
very tedious, and for 16x16s it becomes impractical. So most
people are going to read in data from a drawing tool, then
generate the C source automatically. So even there, binary 
literals aren't huge win.
It is sometimes useful to print out a value in binary, a
%b format specifier to printf() might get a bit of use for
debugging bit-racks.  

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

#72217

On 08/10/2015 21:28, Malcolm McLean wrote:
> On Thursday, October 8, 2015 at 7:36:17 PM UTC+1, David Brown wrote:

>> But it would be hard to believe that the suggestion has not been made to
>> include binary literals in future C standards,

> I can't really think of a use other than low end bit-mapped,
> character cell-based graphics. But whilst the binary literal
> will allow you to see the bit pattern,

That is a pretty good reason for having them!

> editing 8x8s by hand is
> very tedious, and for 16x16s it becomes impractical.

You don't need to edit them, you just need to see them. While minor 
edits are simpler: to move a pattern to the left one bit, just add a 0. 
In any other base, it would mean a completely different number.

You don't use binary often, but it should be there if you need it and 
the cost of having it is negligible. The quibbling is about the process 
of making it part of standard C.

(I've used binary as well as quaternary in actual code. The latter is 
useful in constants made up of 2-bit fields.)

-- 
Bartc

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

#72218

On Thursday, October 8, 2015 at 4:22:12 PM UTC-5, Bart wrote:
> You don't need to edit them, you just need to see them. While minor 
> edits are simpler: to move a pattern to the left one bit, just add a 0. 
> In any other base, it would mean a completely different number.

I've written tools to convert bitmap graphic files to C code, but in cases
where it's necessary to test out slight changes it can be easier to make
them in the source code editor and try them out immediately than to have
to repeat the code-generation process after every change.  I'm good enough
at editing hex that I can often just go ahead and do that, but being able
to tweak the file in binary format would be nicer.

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

#72243

On 08/10/15 22:28, Malcolm McLean wrote:
> On Thursday, October 8, 2015 at 7:36:17 PM UTC+1, David Brown wrote:
>> On 08/10/15 17:25, Keith Thompson wrote:
>>
>> But it would be hard to believe that the suggestion has not been made to 
>> include binary literals in future C standards, and since there is no 
>> problem with precedent or implementation (at least, not now - there may 
>> have been few implementations before C99 was written), it seems 
>> reasonable to suspect that it has been rejected for similar reasons to 
>> Tim's - that few people need them, and there are existing ways to get a 
>> similar effect without changing the language.
>>
> I can't really think of a use other than low end bit-mapped,
> character cell-based graphics. But whilst the binary literal
> will allow you to see the bit pattern, editing 8x8s by hand is
> very tedious, and for 16x16s it becomes impractical. So most
> people are going to read in data from a drawing tool, then
> generate the C source automatically. So even there, binary 
> literals aren't huge win.
> It is sometimes useful to print out a value in binary, a
> %b format specifier to printf() might get a bit of use for
> debugging bit-racks.  
> 

It has already been mentioned (many times) that binary literals are
mainly of interested to low-level embedded developers, rather than "big
system" programmers.  When dealing with hardware registers and the like,
binary literals are sometimes nice to have (not /essential/, but nice -
leading to clearer code).

And while editing character patterns like this may seem tedious to you,
it is certainly something that is done in small systems with small
displays.  And I can assure you it is vastly easier with binary literals
than using hex literals!  (Although to be honest, I usually make use of
Python scripts to generate the code for such character fonts.)

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

#72267

On Friday, October 9, 2015 at 3:25:10 AM UTC-5, David Brown wrote:
> And while editing character patterns like this may seem tedious to you,
> it is certainly something that is done in small systems with small
> displays.  And I can assure you it is vastly easier with binary literals
> than using hex literals!  (Although to be honest, I usually make use of
> Python scripts to generate the code for such character fonts.)

If one has to generate a 64+ character font, there are generally easier ways
than editing them into a program's text.  On the other hand, there are a fair
number of cases where a program will need a one-off symbol.  Being able to
say:

    void show_smiley(int x, int y)
    {
      unsigned char const smile[8] = {
        0b00111100,
        0b01000010,
        0b10100101,
        0b10011001,
        0b10100101,
        0b10011001,
        0b01000010,
        0b00111100};
      show_8x8(x, y, smile);
    }

may be nicer than having to fire up a graphics editor to draw one shape, and
if the code contains a number of shapes that are used once each at separate
places in the code, it may be better to define each at the point of use than
to have a global graphic object which contains all such shapes and then keep
that synchronized with an "enum" which would for each shape create an
identifier which corresponds to the appropriate symbol.

I am reminded, however, of another couple features I've long wished for: a
form of static const compound literal which would allow the compiler to share
parts of different literals.  At present, given

    printf("cool!");
    printf("That's really cool!");

compilers are allowed to pass the printf a pointer into the second string.
It would be helpful to have a means by which the above could be written as:

    void show_smiley(int x, int y)
    {
      show_8x8(x, y,
        (static unsigned char const smile[8]) {
          0b00111100,
          0b01000010,
          0b10100101,
          0b10011001,
          0b10100101,
          0b10011001,
          0b01000010,
          0b00111100} );
    }

and have the compiler (and/or linker) be allowed to have "smile" reuse the
storage of any other static constant containing the same data.  If the
code contains two smiley face characters which are used for different
purposes, and they happen to be identical in the present version of the
code but may need to change for different reasons, having the code include
both separately but then having a compiler share the data for them would
often more efficient than having each receive its own copy of the data, but
would be safer than trying to have them use the same object identified in
source code [since in the latter scenario, a changing one might inadvertently
change the other].

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

#72474

On 09/10/15 17:35, supercat@casperkitty.com wrote:
> On Friday, October 9, 2015 at 3:25:10 AM UTC-5, David Brown wrote:
>> And while editing character patterns like this may seem tedious to you,
>> it is certainly something that is done in small systems with small
>> displays.  And I can assure you it is vastly easier with binary literals
>> than using hex literals!  (Although to be honest, I usually make use of
>> Python scripts to generate the code for such character fonts.)
>
> If one has to generate a 64+ character font, there are generally easier ways
> than editing them into a program's text.  On the other hand, there are a fair
> number of cases where a program will need a one-off symbol.  Being able to
> say:
>
>      void show_smiley(int x, int y)
>      {
>        unsigned char const smile[8] = {
>          0b00111100,
>          0b01000010,
>          0b10100101,
>          0b10011001,
>          0b10100101,
>          0b10011001,
>          0b01000010,
>          0b00111100};
>        show_8x8(x, y, smile);
>      }
>
> may be nicer than having to fire up a graphics editor to draw one shape, and
> if the code contains a number of shapes that are used once each at separate
> places in the code, it may be better to define each at the point of use than
> to have a global graphic object which contains all such shapes and then keep
> that synchronized with an "enum" which would for each shape create an
> identifier which corresponds to the appropriate symbol.

That is a good example.  Simple character LCD displays are very common 
in embedded systems - these typically have 8x8 pixel characters, with 
the standard ASCII in ROM and space for 8 user-defined characters.  So 
you want just a few characters in the code - perhaps accented letters 
for different languages, or a °C symbol, or something like that.  Binary 
literals are ideal for such uses.

>
> I am reminded, however, of another couple features I've long wished for: a
> form of static const compound literal which would allow the compiler to share
> parts of different literals.  At present, given
>
>      printf("cool!");
>      printf("That's really cool!");
>
> compilers are allowed to pass the printf a pointer into the second string.
> It would be helpful to have a means by which the above could be written as:
>
>      void show_smiley(int x, int y)
>      {
>        show_8x8(x, y,
>          (static unsigned char const smile[8]) {
>            0b00111100,
>            0b01000010,
>            0b10100101,
>            0b10011001,
>            0b10100101,
>            0b10011001,
>            0b01000010,
>            0b00111100} );
>      }
>
> and have the compiler (and/or linker) be allowed to have "smile" reuse the
> storage of any other static constant containing the same data.  If the
> code contains two smiley face characters which are used for different
> purposes, and they happen to be identical in the present version of the
> code but may need to change for different reasons, having the code include
> both separately but then having a compiler share the data for them would
> often more efficient than having each receive its own copy of the data, but
> would be safer than trying to have them use the same object identified in
> source code [since in the latter scenario, a changing one might inadvertently
> change the other].
>

The compiler (and/or linker) is already free to combine such constant 
data in certain ways.  The C standard requires that different objects 
(including const objects, even if they are static) have different 
addresses.  But as long as you don't take the address of the constant 
data, merging is fine (the compiler doesn't even have to make the object 
in addressable memory if it is not needed).

gcc (to illustrate the principle) has "-fmerge-constants" that will 
combine such constants when it is possible to do so without breaking the 
standards, and "-fmerge-all-constants" to allow merging even when it 
/does/ break the rules.

But I don't know any way you can tell a compiler that you need to use 
the addresses of some particular constants, but don't mind if they are 
merged, while retaining conforming behaviour for other constants.

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

#72522

On Sunday, October 11, 2015 at 8:18:58 AM UTC-5, David Brown wrote:
> The compiler (and/or linker) is already free to combine such constant 
> data in certain ways.  The C standard requires that different objects 
> (including const objects, even if they are static) have different 
> addresses.  But as long as you don't take the address of the constant 
> data, merging is fine (the compiler doesn't even have to make the object 
> in addressable memory if it is not needed).

How often does one have objects of significant size whose address is never
taken?  While some objects might be large enough to be worth storing in
shareable form and yet not have their address taken, that would seem rather
rare.

Further, even though semantically something like:

    CREATE_FNORD(foo, 12, 34, 56);
    ...
    do_something(&foo);

might be semantically equivalent to:

    do_something(NEW_FNORD(12,34,56));

I being able to create constants in-line would seem much more convenient
than having to create them elsewhere.  I find it curious that C99 allowed
for the creation of automatic-lifetime literals, and allows code to take
their address, but has no handling for static-lifetime constants.

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

#72590

On 11/10/15 23:53, supercat@casperkitty.com wrote:
> On Sunday, October 11, 2015 at 8:18:58 AM UTC-5, David Brown wrote:
>> The compiler (and/or linker) is already free to combine such constant 
>> data in certain ways.  The C standard requires that different objects 
>> (including const objects, even if they are static) have different 
>> addresses.  But as long as you don't take the address of the constant 
>> data, merging is fine (the compiler doesn't even have to make the object 
>> in addressable memory if it is not needed).
> 
> How often does one have objects of significant size whose address is never
> taken?  While some objects might be large enough to be worth storing in
> shareable form and yet not have their address taken, that would seem rather
> rare.

Let me be slightly more accurate here - if the compiler knows that you
are not /comparing/ addresses in any way, then (I think) it is safe to
combine or merge constants.

So if your code has these functions:

char makeHexDigit(unsigned int i) {
    static const char digs[] = {'0', '1', '2', '3', '4', '5', '6', '7',
                                '8', '9', 'a', 'b', 'c', 'd', 'e', 'f'};
    if (i > 15) return '?';
    return digs[i];
}

char makeDecDigit(unsigned int i) {
    static const char digs[] = {'0', '1', '2', '3', '4', '5', '6', '7',
                                '8', '9'};
    if (i > 9) return '?';
    return digs[i];
}

Although the program effectively takes the address of these const
objects (for the array look-up), the compiler can safely merge them.  (A
quick test with gcc 4.9 fails to merge, even with -fmerge-all-constants.
 But in theory, it could!)


> 
> Further, even though semantically something like:
> 
>     CREATE_FNORD(foo, 12, 34, 56);
>     ...
>     do_something(&foo);
> 
> might be semantically equivalent to:
> 
>     do_something(NEW_FNORD(12,34,56));
> 
> I being able to create constants in-line would seem much more convenient
> than having to create them elsewhere.  I find it curious that C99 allowed
> for the creation of automatic-lifetime literals, and allows code to take
> their address, but has no handling for static-lifetime constants.
> 

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

#72591

On Monday, October 12, 2015 at 2:17:20 AM UTC-5, David Brown wrote:
> On 11/10/15 23:53, supercat wrote:

> > How often does one have objects of significant size whose address is never
> > taken?  While some objects might be large enough to be worth storing in
> > shareable form and yet not have their address taken, that would seem rather
> > rare.
> 
> Let me be slightly more accurate here - if the compiler knows that you
> are not /comparing/ addresses in any way, then (I think) it is safe to
> combine or merge constants.

Perhaps I should have been more accurate as well--how often does one have
objects of significant size whose addresses won't get exposed to code which
the compiler can't "see into"?

I wish C would add some qualifiers to pointer parameters which would let
caller-side code know what may be done with them.  A lot of optimizations
which would presently require that a compiler see into functions could
be implemented without such a requirement if header files could indicate
things like whether a function might persist the arguments it receives.
Actually, going along with that, I'd like to see the meaning of "register"
loosened slightly, so that it would be permissible to use the address of
a register-qualified variable provided that a compiler could guarantee that
(unless a called method lies about its parameter usage) the compiler could
determine the lifetime of every copy of that address.  Thus, given

    register int a = 0;
    a+=proc1();
    a+=proc2();
    proc3(&a);
    a+=proc4();
    a+=proc5();
    return a;

a compiler would be allowed to keep 'a' in a callee-saved register during
the calls to proc1, proc2, proc4, and proc5, without having to be able to
see into those methods, provided that proc3's argument was marked as being
non-persistable; if proc3's argument wasn't so marked, the code should
refuse compilation.

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

#72374

On Friday, October 9, 2015 at 9:25:10 AM UTC+1, David Brown wrote:
> On 08/10/15 22:28, Malcolm McLean wrote:
> > On Thursday, October 8, 2015 at 7:36:17 PM UTC+1, David Brown wrote:
> >> On 08/10/15 17:25, Keith Thompson wrote:
> >>
> >> But it would be hard to believe that the suggestion has not been made to 
> >> include binary literals in future C standards, and since there is no 
> >> problem with precedent or implementation (at least, not now - there may 
> >> have been few implementations before C99 was written), it seems 
> >> reasonable to suspect that it has been rejected for similar reasons to 
> >> Tim's - that few people need them, and there are existing ways to get a 
> >> similar effect without changing the language.
> >>
> > I can't really think of a use other than low end bit-mapped,
> > character cell-based graphics. But whilst the binary literal
> > will allow you to see the bit pattern, editing 8x8s by hand is
> > very tedious, and for 16x16s it becomes impractical. So most
> > people are going to read in data from a drawing tool, then
> > generate the C source automatically. So even there, binary 
> > literals aren't huge win.
> > It is sometimes useful to print out a value in binary, a
> > %b format specifier to printf() might get a bit of use for
> > debugging bit-racks.  
> > 
> 
> It has already been mentioned (many times) that binary literals are
> mainly of interested to low-level embedded developers, rather than "big
> system" programmers.  When dealing with hardware registers and the like,
> binary literals are sometimes nice to have (not /essential/, but nice -
> leading to clearer code).
>
But normally you use masks to define which bits are set or clear.
I wouldn't imagine that many people would type in a binary literal
to specify that LATCH, which is bit 6 of some hardware register
or other, should be cleared. I don't say never, but normally that
would only be at a very early stage when maybe it's not clear that
the bits have been assigned correctly. 
> 
> And while editing character patterns like this may seem tedious to you,
> it is certainly something that is done in small systems with small
> displays.  And I can assure you it is vastly easier with binary literals
> than using hex literals!  (Although to be honest, I usually make use of
> Python sc...
>
You want a little tool that lets you twiddle the bits with a mouse,
then dumps out C source. These days you can knock up something like
that very quickly. 

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

#72380

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Friday, October 9, 2015 at 9:25:10 AM UTC+1, David Brown wrote:
<snip>
>> And while editing character patterns like this may seem tedious to you,
>> it is certainly something that is done in small systems with small
>> displays.  And I can assure you it is vastly easier with binary literals
>> than using hex literals!  (Although to be honest, I usually make use of
>> Python sc...
>>
> You want a little tool that lets you twiddle the bits with a mouse,
> then dumps out C source. These days you can knock up something like
> that very quickly.

Or just use your favourite drawing tool and save or convert the result
as an X11 bitmap file -- the format is C code.

-- 
Ben.

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

#72381

On 10/10/2015 08:31, Malcolm McLean wrote:
> On Friday, October 9, 2015 at 9:25:10 AM UTC+1, David Brown wrote:

>> It has already been mentioned (many times) that binary literals are
>> mainly of interested to low-level embedded developers, rather than "big
>> system" programmers.  When dealing with hardware registers and the like,
>> binary literals are sometimes nice to have (not /essential/, but nice -
>> leading to clearer code).
>>
> But normally you use masks to define which bits are set or clear.
> I wouldn't imagine that many people would type in a binary literal
> to specify that LATCH, which is bit 6 of some hardware register
> or other, should be cleared.

How would you do it instead?

And where would the information that LATCH is bit 6 come from? Often, it 
will be from a representation in a data sheet laying out the individual 
bits in a register or port, and that is binary.

Then you have the choice of creating a mask, if that is what is needed, 
using 0100, or 0x40x, or 64, or 1<<6, or 0b1000000.

Why shouldn't people have that extra choice? And quite likely, only that 
binary option directly corresponds to the data sheet so that it doesn't 
need that extra thought process between what's in the docs, and what's 
written in the source code.

If there several masks involved for the same port, they can be laid out 
like this:

//                     .LC. .XY.
  #define latch_mask 0b_0100_0000
  #define ...        0b_0010_0000
  #define ...        0b_0000_0110

Then it helps to build up a useful visual map of how these various bits 
relate to each, that is not as easy with any of those other ways of 
representing them in the source code.

-- 
Bartc

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

#72384

On Saturday, October 10, 2015 at 11:01:58 AM UTC+1, Bart wrote:
> On 10/10/2015 08:31, Malcolm McLean wrote:
>
> > But normally you use masks to define which bits are set or clear.
> > I wouldn't imagine that many people would type in a binary literal
> > to specify that LATCH, which is bit 6 of some hardware register
> > or other, should be cleared.
> 
> How would you do it instead?
> 
#define LATCH (1 << 6)
>
> And where would the information that LATCH is bit 6 come from? Often, it 
> will be from a representation in a data sheet laying out the individual 
> bits in a register or port, and that is binary.
>
Typically a data sheet has a little graphic with boxes representing
the bits, to make it absolutely clear and unambiguous which bit means
which. But you can't easily include graphics in C source (if
someone has a modern emacs, will an svg comment be displayed
as an image?).
> 
> Then you have the choice of creating a mask, if that is what is needed, 
> using 0100, or 0x40x, or 64, or 1<<6, or 0b1000000.
> 
> Why shouldn't people have that extra choice? 
>
Adding choices makes code harder to read, as some people go for
one method, some for others. Octal, for example is bad, because 
octal numbers look too much like decimal numbers (hex numbers can as
well, but if you have more than one or two, there will be a letter
digit, which reminds the reader that he is looking at hex).
Binary doesn't have that drawback, it's unlikely to be confused.
However the numbers just form a meaningless pattern to the human
eye (unless they're actually graphics), it's virtually impossible
to make much sense of more than a tiny amount of binary data.
>
> If there several masks involved for the same port, they can be laid out 
> like this:
> 
> //                     .LC. .XY.
>   #define latch_mask 0b_0100_0000
>   #define ...        0b_0010_0000
>   #define ...        0b_0000_0110
> 
> Then it helps to build up a useful visual map of how these various bits 
> relate to each, that is not as easy with any of those other ways ...
>

That's true. There's a little bit of a case for binary, and that
would be a good use.

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

#72416

On Saturday, October 10, 2015 at 5:43:59 AM UTC-5, Malcolm McLean wrote:
> Adding choices makes code harder to read, as some people go for
> one method, some for others. Octal, for example is bad, because 
> octal numbers look too much like decimal numbers (hex numbers can as
> well, but if you have more than one or two, there will be a letter
> digit, which reminds the reader that he is looking at hex).

I've long wished C (or any language which uses Octal) would define a
representation other than a sequence of digits with a leading zero.  It
may take awhile for enough compilers to support such a representation
that programmers would start using it in preference to the leading-zero
form and turning on a warning any time the leading-zero form was used,
but if a new form were devised today, it might be possible to deprecate
the leading-zero form outside of "compatibility mode" while retaining
the occasionally-useful ability to specify octal numbers.  I find it
odd that some recent languages have chosen to borrow C's use of leading
zero for octal, though fortunately at least JavaScript quickly deprecated
it (though IIRC no alternative form was defined).

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

#72418

On Saturday, October 10, 2015 at 5:43:59 AM UTC-5, Malcolm McLean wrote:
> > Then it helps to build up a useful visual map of how these various bits 
> > relate to each, that is not as easy with any of those other ways ...

Binary really isn't all that wonderful, though it is often better than
alternatives.  What would seem even nicer would be if there were a way to
write a value which combined base-2, base-4, base-8, and base-16 in a
single constant.  In some ways, macros could be better for this than
a direct number-base feature, but there's no clean way I can think of to
write a macro that could take a sequence of concisely-written field
specifications along with the correct length, validate that the length
matched the combined length of the fields, and yield the resulting value.

If C's preprocessor was a little more flexible, and included functions to
e.g. force evaluation of intermediate macros, or to take the text of an
argument and output it as a comma-separated list, then the Standard could
include a few pre-defined macros to handle various formats and also
allow user code to specify macros for scenarios where the pre-defined ones
weren't quite a good fit.

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

#72475

On 10/10/15 09:31, Malcolm McLean wrote:
> On Friday, October 9, 2015 at 9:25:10 AM UTC+1, David Brown wrote:
>> On 08/10/15 22:28, Malcolm McLean wrote:
>>> On Thursday, October 8, 2015 at 7:36:17 PM UTC+1, David Brown wrote:
>>>> On 08/10/15 17:25, Keith Thompson wrote:
>>>>
>>>> But it would be hard to believe that the suggestion has not been made to
>>>> include binary literals in future C standards, and since there is no
>>>> problem with precedent or implementation (at least, not now - there may
>>>> have been few implementations before C99 was written), it seems
>>>> reasonable to suspect that it has been rejected for similar reasons to
>>>> Tim's - that few people need them, and there are existing ways to get a
>>>> similar effect without changing the language.
>>>>
>>> I can't really think of a use other than low end bit-mapped,
>>> character cell-based graphics. But whilst the binary literal
>>> will allow you to see the bit pattern, editing 8x8s by hand is
>>> very tedious, and for 16x16s it becomes impractical. So most
>>> people are going to read in data from a drawing tool, then
>>> generate the C source automatically. So even there, binary
>>> literals aren't huge win.
>>> It is sometimes useful to print out a value in binary, a
>>> %b format specifier to printf() might get a bit of use for
>>> debugging bit-racks.
>>>
>>
>> It has already been mentioned (many times) that binary literals are
>> mainly of interested to low-level embedded developers, rather than "big
>> system" programmers.  When dealing with hardware registers and the like,
>> binary literals are sometimes nice to have (not /essential/, but nice -
>> leading to clearer code).
>>
> But normally you use masks to define which bits are set or clear.
> I wouldn't imagine that many people would type in a binary literal
> to specify that LATCH, which is bit 6 of some hardware register
> or other, should be cleared. I don't say never, but normally that
> would only be at a very early stage when maybe it's not clear that
> the bits have been assigned correctly.

You can write that in many ways:

	LATCH &= ~(1u << 6);
	LATCH &= ~0x40;
	LATCH &= 0xbf;
	LATCH &= ~0b01000000;		// Or 0b0100'0000 in C++
	LATCH &= 0b10111111;		// Or 0b1011'1111 in C++

(This also shows how nice the digit separator in C++ is - I hope that 
compilers start to accept that as a common extension in C too.)

Doing a single bit to hex conversion mentally is not hard (when you are 
used to it), and writing it in the form (1u << 6) is also clear and 
simple.  But if you are combining a number of bits, binary literals can 
be a neat way of writing it.  To set bits 2, 3 and 6, you could use:

	LATCH |= ((1u < 2) | (1u << 3) | (1u << 6));
	LATCH |= 0x46;
	LATCH |= 0b01000110;		// Or 0b0100'0110 in C++



>>
>> And while editing character patterns like this may seem tedious to you,
>> it is certainly something that is done in small systems with small
>> displays.  And I can assure you it is vastly easier with binary literals
>> than using hex literals!  (Although to be honest, I usually make use of
>> Python sc...
>>
> You want a little tool that lets you twiddle the bits with a mouse,
> then dumps out C source. These days you can knock up something like
> that very quickly.
>

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web