0

I'm studying socket programming and I learned inet_addr function. But I'm confused how can I handle in_addr_t type.

inet_addr function returns in_addr_t type which is uint32_t, then do I have to use uint32_t type variable to handle it?

In the book, example handles it as unsigned long type, but I don't understand why this way is used.

unsigned long conv_addr = inet_addr(addr1); // unsigned long == uint32_t?
melpomene
  • 84,125
  • 8
  • 85
  • 148
coder
  • 95
  • 1
  • 1
  • 5
  • 3
    "*In the book*" - what book? – melpomene Aug 06 '18 at 05:35
  • 3
    I'd just declare the variable as `in_addr_t` because that's what the function returns. – melpomene Aug 06 '18 at 05:37
  • It's just korean book which teaches socket programming – coder Aug 06 '18 at 05:37
  • When you say the `in_addr_t` type is `uint32_t`, is there documentation saying that, or did you look through the source code (likely in some system or implementation header file) to see how `in_addr_t` is defined? If you got it from source code, that is not equivalent to an assertion that `in_addr_t` will necessarily be defined as `uint32_t` in other versions of the software. – Eric Postpischil Aug 06 '18 at 05:40

2 Answers2

0

You do not have to use uint32_t to handle the value returned from inet_addr. You can use any type that can represent any value that might be returned or that you might use in a calculation. But why not use the uint32_t or the in_addr_t type?

Eric Postpischil
  • 195,579
  • 13
  • 168
  • 312
  • Then `uint32_t`==`in_addr_t`==`unsigned int`? – coder Aug 06 '18 at 05:40
  • 1
    @coder: You should not assume types are identical unless you have documentation asserting that they are. A release of software X version N might define type `foo` to be `uint32_t`, but release N+1 of the software might define type `foo` to be `unsigned long`. Additionally, the width of `unsigned int` and `unsigned long` vary from C implementation to C implementation. C guarantees that `unsigned long` is at least as wide as `uint32_t`, so using `unsigned long` to hold a `uint32_t` variable is safe. But why would you choose to use a possibly wider type without needing too? – Eric Postpischil Aug 06 '18 at 05:41
  • @coder `unsigned int` is not guaranteed to be exactly 32 bits wide. `in_addr_t` is [defined as `uint32_t`](http://pubs.opengroup.org/onlinepubs/009695399/basedefs/netinet/in.h.html#tag_13_32), however. – melpomene Aug 06 '18 at 05:43
  • @EricPostpischil @melpomene Ah... I got it, then `unsigned long` is for safety and `in_addr_t` is correct for this situation. right? – coder Aug 06 '18 at 05:49
0

You may use long type also for inet_addr() function since most of the architecture use 32 bits(4 bytes) for long type but it is not always applicable

Some architecture use 64 bits for long type.. LP64 convention use 64 bits for long type

But the size of uint32_t is always 32 bits independent of convention the compiler is following.

If you are writing programs using MSVC, it uses 32 bits for long type.

For gcc, it depends on computer hardware and implementation of GCC.

It is safe to use unsigned long for assigning to the return type of inet_addr() when you are confident with long size is 32 bits.

Recommended to use uint32_t(aka unsigned 32 bit memory) for inet_addr(), so you don't need to care about the size of long type at all...

  • 3
    "For gcc too, it uses 32 bits for long." --> sure about that? – chux - Reinstate Monica Aug 06 '18 at 06:14
  • 2
    *since most of the architecture use 32 bits(4 bytes) for long type* [That's not true.](https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models) That's true mostly for on just Windows. Just about every other 64-bit architecture extant uses a 64-bit `long`. – Andrew Henle Aug 06 '18 at 09:27
  • gcc depends on system architecture.[Refer here](http://www.crasseux.com/books/ctutorial/Integer-variables.html). Since most of the systems are 64 bit architecture nowadays, gcc uses 64 bits for long but still depends on system architecture – Karthikeyan Subramanian Aug 07 '18 at 07:04