Btw how did you get the contents of data section ?

In linux: First you generate the object file: gcc -c file.c then use objdump to extract the object file’s section: objdump -s file.o also you can read the manual if you need something else

That is why its always adviced to use: const char* x instead of char* x so you can detect problems at compile time. The string literal is in read-only section and mustn't be tampered with during program execution.

#include <stdio.h> #include <stdlib.h> int main() { int x; for(x=10;x>=1;x--) printf("%d ",x); return 0; } ——————————————— #include <stdio.h> #include <stdlib.h> int main() { int x; for(x=10;x>=1;x--) printf("%d ",&x); return 0; } ———————————————-- Anyone can explain about these 2 codes? what & do in printf function?

I tried to write a code to merge two array and make a new distinct array Can anyone tell me what's wrong with this code

Write a C program that consist of structure called student with data members roll,name and GPA .Store the studnet information of 10 studnets and display the record of student in ascending order as per the gpa score.

Write a C program that consist of structure called student with data members roll,name and GPA .Store the studnet information of 10 studnets and display the record of student in ascending order as per the gpa score.

Write a C program that consist of structure called student with data members roll,name and GPA .Store the studnet information of 10 studnets and display the record of student in ascending order as per the gpa score.

hello bodys, why use malloc > 32MB, cost much more time

As a beginner in CSE should I start with C or C++ ?

static void BM_MORE(benchmark::State& state) { char *s = nullptr; const long long size = 34000000; for (auto _ : state) { s = (char*)malloc(sizeof(char)*size); free(s); } } BENCHMARK(BM_MORE); static void BM_LESS(benchmark::State& state) { char *s = nullptr; const long long size = 33000000; for (auto _ : state) { s = (char*)malloc(sizeof(char)*size); free(s); } } BENCHMARK(BM_LESS);

#include <stdio.h> #include <stdlib.h> int main() { int x; for(x=10;x>=1;x--) printf("%d ",x); return 0; } ——————————————— #include <stdio.h> #include <stdlib.h> int main() { int x; for(x=10;x>=1;x--) printf("%d ",&x); return 0; } ———————————————-- Anyone can explain about these 2 codes? what & do in printf function?

String ans=""; ans+="-1"; This one gives output as -1 and if I do ans+='-1'; This one gave output 1 How

in the most likely case - '-1' is an int whose value is 0x2D31 (0x2D is ascii for '-' and 0x31 is ascii for '1')

you convert this int to a char when using the += function, which causes integer overflow

So it leaves the 2D part?

depends on whether char is signed. if it is signed, then this is undefined behaviour. if it is unsigned, then yes it just does a % 0x100 which leaves only the 0x31.

If it is unsigned character ..then there will be extra bits for sign...so we don't know what part will be left ..is that it?

> unsigned character > extra bits for sign ?

You said..while converting to char...some bits will be left

char is an integral type. integral types can either be signed or unsigned. for signed integral types, overflow is undefined. for unsigned integral types, modular arithmetic is used to wrap the value around.

test code #include <iostream> #include <limits> int main() { std::cout << std::numeric_limits<char>::is_signed << '\n'; }

in the most likely case - '-1' is an int whose value is 0x2D31 (0x2D is ascii for '-' and 0x31 is ascii for '1')

It may be 0x312D0000 as well depending on whether the system is big endian or little endian.

It may be 0x312D0000 as well depending on whether the system is big endian or little endian.

no. https://docs.microsoft.com/en-us/cpp/cpp/string-and-character-literals-cpp?view=msvc-160#microsoft-specific https://gcc.gnu.org/onlinedocs/cpp/Implementation-defined-behavior.html https://github.com/llvm/llvm-project/blob/main/clang/lib/Lex/LiteralSupport.cpp#L1416

I meant to say 0x0000312D but I said 0x312D0000 instead. Yes but you ignored the "this is Microsoft specific" implementation. This need not be the case for all machines. As far as the standard is concerned, it just requires multi character literals to be processed from left to right. There is no standard requirement on how the actual int value is constructed. So '-1' may be stored in memory from low address to high address as 0x2D 0X31. Assuming it is a little endian machine the int value will be 0x312D. The int value need not always be calculated using shifting. The standard leaves that to the implementation. Microsoft does it this way and documents it. It is possible for an implementation to interpret the bytes in memory itself as the int value as long as it documents it. The point here is that the actual int value is implementation specific and need not always be 0x2D31

String ans=""; ans+="-1"; This one gives output as -1 and if I do ans+='-1'; This one gave output 1 How

btw i hope you understood the actual problem. in C/C++ " " and ' ' are not interchangeable. one defines string literals, the other defines character constants, and sometimes (when you try to jam multiple characters in a single ' ') integer constants,

you said "depending on whether the system is big endian or little endian". my "no." in the last message was just that it did not NECESSARILY depend on endianness. i am not arguing that the value is not implementation defined. intel is little-endian and i get 0x2D31 on my PC. gcc, clang, msvc all implement it the same way regardless of endianness. microsoft's special behaviour is that assigning to char and wchar are valid, and L'...' multicharacter literals just take the first character and ignore everything else (no special ints). edit: new text in ALL-CAPS

Why we use auto keyword in c++ with simple example

Yes it may depend on endianness which can be documented by an implementation as such. You get 0x2d31 on your little endian system because your implementation uses shifting. My point is that shifting isn't always the only way just because MSVC, GCC use that. It would be perfectly valid for an implementation to document that the value of a multi character literal will be based on the endianness of the architecture and could also document which character it stored in the low address and which character in the high address. I am saying this because you said earlier that the multi character literal '-1' can never have the value 0x312d and that it will always be only 0x2d31 My point is that it can have the value 0x312d if the implementation chooses to decide a value based on the endianness of the system. So your saying that it can never depend on endianness is wrong. It can if an implementation chooses to do so which would be perfectly valid Implementation Defined Behavior. Btw multi character literals are only conditionally supported meaning a compiler can even flag them as an error.

> It would be perfectly valid for an implementation... yes it would, but > It may be 0x312D0000 0x0000312D as well depending on whether the system is big endian or little endian. this statement is still incorrect. it may definitely be 0x312D, but that value may or may not depend on whether the system is big endian or little endian.

Why? If an implementation decides that a multicharacter literal like '-1' would store '-' in a low byte and '1' in a high byte and then interpret the two bytes as an int using the underlying endianness and padding 0x00 in front why would that not be an implementation dependent Behavior? In other words, the same compiler could interpret 'abcd' as 0x31323334 on one endian system and 0x34333231 on another. This is valid implementation defined Behavior.

yes it would be a perfectly valid implementation. however, if an implementation decides that the characters will be parsed right-to-left (instead of left-to-right), shifting left every time a new character is read, then the value is still 0x0000312D. it would still be implementation defined behaviour, but it won't depend on endianness. the shift operator abstracted the endianness it away.

No. You are assuming there is a shift operation happening. Read my message above. There is no shift operation there. The compiler just stores the multi character literal in memory and reads the memory as it is to get the int which depends on endianness. In cases where there are less than sizeof(int) characters, the compiler can pad 0s in front. In particular read the example for 'abcd' that I have above.

i am not talking about your hypothetical implementation. i am talking about a different hypothetical implementation to support my claim "it may definitely be 0x312D, but that value (may or) may not depend on whether the system is big endian or little endian."

you said "depending on whether the system is big endian or little endian". my "no." in the last message was just that it did not NECESSARILY depend on endianness. i am not arguing that the value is not implementation defined. intel is little-endian and i get 0x2D31 on my PC. gcc, clang, msvc all implement it the same way regardless of endianness. microsoft's special behaviour is that assigning to char and wchar are valid, and L'...' multicharacter literals just take the first character and ignore everything else (no special ints). edit: new text in ALL-CAPS

@SilhouetteInDark ok i fixed this message

Lol. You dont have to go and change messages in the past. As long as we understand what the other person is saying, it is fine.

i mean correcting that text changes the nature of the debate. now it is just > It may be 0x312D0000 0x312D as well depending on whether the system is big endian or little endian. >> no (not necessarily) > Where did i say that it was necessary? it is just that there can be an implementation like this. >> true

So there is nothing to debate then as long as you agree that there may be a hypothetical implementation which takes endianness into account. How many implementations do that is a different question. Like you showed, GCC, Clang and MSVC just use shifting and MSVC has this added quirk of storing the characters in memory from left to right starting from low address to high address while it is stored the opposite way in GCC. MSVC implementation is more debug friendly. So 'abcd' would display as abcd in a debugger while it will be displayed as 'dbca' for GCC. Both would evaluate to the same int value however using the same shifting logic. But that is anyway digression.

Hey guys this is to anyone that want to learn c language 🙂 so we can learn together oh if you can mentor us then we can learn from you that's good please please help your brother