Char Pointer After Char Array

[CommonTater]

Enable Microsoft extensions...

What we are telling you is that for a string intializer to work correctly you need space for the trailing 0... you do not get to simply ignore it.  The compiler will want to put it there when crunching your code.  The result will be a buffer overrun leaving you with unknown contents in at least one section of your struct.  Moreover you are removing the trailing 0 safeguard that all strings carry.

If you absolutely insist upon putting single characters --and treating the array as such-- then your use of four separate characters ... '1', '2', '3', '4', "Test" ... from an earlier message is the correct intializer. Although you might be in for a bit of a surprise when you find out it's actually loaded with numerical values 49, 50, 51 and 52, which are the ascii equivalents of the characters you specified.

If you want numerical values in your char array you would use 1, 2, 3, 4, "Test"

If you change c in your struct to an int, the correct intializer is  1234, "Test"
 
As Ralf points out you are very unwise to ignore the warning... because the result would be that your char c[4] variable would be loaded with '1' followed by whatever garbage was floating around in memory at the time. Your intializer will have failed and almost certainly your program would misbehave in ways that could be next to impossible to troubleshoot. 

It's called "undefined behaviour" and C programmers avoid it like the plague.

[CommonTater]

This would be perfectly acceptable. However, I wanted to access each byte without >> and/or &.

If you put the value 1234 in an integer, you will not get back 3 by accessing the third byte... Integers store numbers in binary... in this case as...

00000000 00000000 00000100 11010010   (1234 dec)

Accessing the third byte would get you ... 4 and the last byte would get you 210.

Why don't you spend a couple of minutes and tell us what you're trying to do...
Odds are we can help you get it going.

[Bitbeisser]

This would be perfectly acceptable. However, I wanted to access each byte without >> and/or &.

If you put the value 1234 in an integer, you will not get back 3 by accessing the third byte... Integers store numbers in binary... in this case as...

00000000 00000000 00000100 11010010   (1234 dec)

Accessing the third byte would get you ... 4 and the last byte would get you 210.

Why don't you spend a couple of minutes and tell us what you're trying to do...
Odds are we can help you get it going.

He is not trying to put the "numeric value" of 1234 but the single characters. This "might" work due to the weak (non-existent) type checking of C, on some compilers at least. But as I mentioned, it's just a side effect, not guaranteed to work on any compiler or any CPU architecture. And bad programming is still bad programming, regardless of what "extensions" are being enabled...

Again, that warning message that Pelle's C is emitting is absolutely to the point and should rather be taken serious than trying to find ways to work around or even call it a compiler bug. As he found out himself, there is a legit way to do what he intended to do...

Ralf

[CommonTater]

Again, that warning message that Pelle's C is emitting is absolutely to the point and should rather be taken serious than trying to find ways to work around or even call it a compiler bug. As he found out himself, there is a legit way to do what he intended to do...

As I suggested, turn the warning level all the way up and treat every warning as a problem to be fixed by adjusting source code.  This should be SOP at least until the individual understands C well enough to selectively ignore certain warnings... But clearly not this one about bad initializers.

[Monolith]

We seem to be going around in circles. I don't need help. I made a mistake in how to initialize a char array. I never wanted a trailing zero. I had no intention of printing the code. When I said you can use an int type, it was only to make my initial initialization work; that was all I meant by that. It doesn't matter if it is bad coding practice or not. That was not the point. And by the way, it is legit to put multiple char in a single quote. It was added to to Pelles C purposely under the Microsoft extensions.

'Multi-byte' character constants are accepted: 'abc' turns into ('a' << 16) | ('b' << | ('c'). [4.00]

That means this would also compile correctly under Pelles C and MSVC without errors and warnings.

[Bitbeisser]

We seem to be going around in circles. I don't need help. I made a mistake in how to initialize a char array. I never wanted a trailing zero. I had no intention of printing the code. When I said you can use an int type, it was only to make my initial initialization work; that was all I meant by that. It doesn't matter if it is bad coding practice or not. That was not the point.

Well, the point is/was that you were very quick to post this as a compiler bug report

And by the way, it is legit to put multiple char in a single quote. It was added to to Pelles C purposely under the Microsoft extensions.

Sorry, but I don't' call this "legit". It's a lame crutch at best. You won't find anything in either K&R or any of the C standards that supports that kind of usage. It will be flagged with a warning in pretty much all compilers that I know and use. And honestly, I stopped using a Microsoft C compiler sometime in the late '80s, that's when they became too "quirky" to allow me to use any source code on any other compiler...

Ralf

[CommonTater]

And by the way, it is legit to put multiple char in a single quote. It was added to to Pelles C purposely under the Microsoft extensions.

It's not standard C-99 or C-11 ... it is an extension added by Microsoft in their own compilers.  What that means is that it's not going to compile on any compiler that's not using MS extensions...

Relying on non-standard programming to make your program work isn't exactly the smartest thing to do, especially when there are standardized alternatives already available.

It doesn't matter if it is bad coding practice or not. That was not the point.

Actually that's exactly the point Ralf was making... It does matter.
 
As you learn more about programming you're going to find out why it matters... especially when you find your code is suddenly misbehaving after installing a new version of the compiler.
 
http://en.wikipedia.org/wiki/Undefined_behavior
 

[Monolith]

I never said I was going to use this example. I am well aware what is and is not good coding practice. I was used to being able to set multiple bytes at once. That is where is misconception came from.

I am tired of this forum; please delete my account.

[TimoVJL]

ISO/IEC 9899:201x Committee Draft — April 12, 2011 N1570
32 EXAMPLE 8 The declaration
char s[] = "abc", t[3] = "abc";
defines ‘‘plain’’ char array objects s and t whose elements are initialized with character string literals.
This declaration is identical to
char s[] = { 'a', 'b', 'c', '\0' },
t[] = { 'a', 'b', 'c' };

Code: [Select]

const struct_t test = {{'1','2','3','4'}, "Test"};