Re: Keil uVision 2. Time & Date in Filename

"Robert Adsett" <sub2@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1163009930.359721.244120@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Elan Magavi wrote:
"Tom Lucas" <news@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote
in
message news:1163005145.59614.0@xxxxxxxxxxxxxxxxxxxx
"Chris Hills" <chris@xxxxxxxxxxxx> wrote in message
news:TX9u5qB$ZgUFFAcb@xxxxxxxxxxxxxxxxxxxxxxx
In article <4redv1Fr0kcgU1@xxxxxxxxxxxxxxxxxx>, Not Really Me
<scott@validatedQWERTYsoftware.?.?.XYZZYcom.invalid> writes

const unsigned char code CompileDateTime[] = __DATE__ " "
__TIME__;

Or even

const char code CompileDateTime[] = __DATE__ " " __TIME__;

I may be being dense (surely not, I hear you cry) but why is the
omission
of the unsigned desired? I know it depends on compiler but I
thought most
defaulted chars to be unsigned anyway?

I'd have thought the first method was better because it explicitly
states
what's going on and leaves no ambiguity? Is the compiler likely to
use
signed ASCII values when populating the strings from it's Date and
Time
parameters?


Signed ASCII?

Either declaration works fine. There isn't any math done on strings.

First char may be either signed or unsigned depending on the
implementation. Conceptually at least there are three 'character'
types signed char, unsigned char and char. Second, some compilers and
tools will complain about type mismatches when assigning a char array
to either a signed or unsigned char. There is some benefit to having
the storage type match the type every routine that is going to use it
will use. The only real reason I know of to use (un)signed char is if
you are using it as a small integer type rather than a character. OTOH
it doesn't often make a difference in the generated code, it 'just'
decreases the signal to noise ratio from your tools messages.

So, if I'm understanding correctly, Chris is using the conceptual "third
type" of character by omitting the "unsigned" which is essentially
specifying a "don't care" on the signing of the character.

Does the third type actually exist though? Surely in practice all
compilers either define chars as signed or unsigned - normally with an
option to specify which it will use. I can see why that might raise
compiler warnings if you start mixing signs later on in the code but
that would happen anyway.

As Meindert suggests, I always use a typedef header and specify all my
types as schars or uchars and explicitly state their signing status. I
always use unsigned chars for strings and characters and I've never had
a warning for it but I guess that could just be the compilers I've used.


.

Relevant Pages

  • Re: Thou shalt have no other gods before the ANSI C standard
    ... Those are ports whose width matches the ... > character size of the machine. ... So char, or unsigned char if you prefer, ... Well, I have found some, usually a bug in the compiler that you need to ...
    (sci.crypt)
  • Re: The infamous ^Z problem
    ... one character defined for type char */ ... The \0 represents a null character, ... compiler complains about syntax. ... documentation on exactly how to represent hex or octal in c code or ...
    (comp.lang.c)
  • Re: Replacing fgets
    ... Even if u_int8_t is a typedef for unsigned char, ... Didn't your compiler complain here. ... offset is changed ... offset needs to be an int. ...
    (comp.lang.c)
  • Re: array subscript type cannot be `char`?
    ... for which there is a standards compliant compiler are positive? ... in EBCDIC the character '0' has value 0xF0. ... Assuming a specific charset and then talking about signed char will ... May be your compiler guarantees unsigned on an char ...
    (comp.lang.c)
  • Re: Keil uVision 2. Time & Date in Filename
    ... I know it depends on compiler but I thought most ... There isn't any math done on strings. ... First char may be either signed or unsigned depending on the ... you are using it as a small integer type rather than a character. ...
    (comp.arch.embedded)