There is a piece of code for a program compiled in Borland Turbo C. There is such an announcement:

huge x[240001];

When you try to compile this line with the GCC (MinGW32) compiler, an error occurs:

huge does not name a type.

Accordingly questions:

1) What kind of huge ? What is sizeof() in bytes?

2) Is it a structure or what?

3) Where is this type declared? Which header files?

4) How can it be replaced in GCC (MinGW32)?

PS It is desirable exact match replacement, since size, order bytes are important when reading / writing array x[240001] , 10 bytes is written to the file fwrite(x,10,240000,ou); .

  • one
    If the program is compiled in Turbo C, then you can answer the first three questions yourself. - αλεχολυτ
  • @alexolut, provided that he has a Turbo C compiler;) - Qwertiy ♦
  • @Qwertiy well, he somehow found out that it is compiled. It is logical to assume that by compilation. :) - αλεχολυτ
  • @alexolut, "compiled"! = "compiled". That is, I understand that it is written under Turbo C and should be compiled in it, but it cannot verify this and rewrites it under mingw. - Qwertiy ♦
  • one
    @alexolut: Macro substitutions can create a lot of things, incl. turn huge into enum { A, B, C } , and x into (*fun) . But Occam's razor and common sense rule out unreasonable consideration of macro substitutions. - AnT

1 answer 1

What version of the compiler are we talking about? Just since version 3.0, the compiler was simply called Borland C ++, without Turbo. So I have to assume that this is a Turbo C 2.0. Then...

Then it was a 16-bit program that worked in DOS in real mode of the processor, so the pointers there consisted of a segment and offset ... In general, talk for a long time, read better yourself - for example, here or here or somewhere else.

Accordingly, you simply allocated an array of memory using such a memory pointer, but the missing type in C was always perceived as an int .
So it should just be int x[240001]; .

Just keep in mind that int then a 16-bit value.

As for fwrite , it is written 240,000 times 10 bytes in the record you write to the file. This is confusing, because there simply wasn’t such a memory under DOS - all of it was limited to 640KB. So, maybe share the source code - putting it somewhere? It's just interesting to see and figure out what this program is trying to do.

"I think so" (c) Pooh

  • In this case, fwrite is not combined with an array declaration. - Qwertiy ♦
  • one
    @Qwertiy: What is written in the question about fwrite is nonsense, which is not combined with anything at all. - AnT
  • @Qwertiy They want to write something incomprehensible there, that's why I asked for source code. I can't believe it at all ... - Harry
  • one
    @Qwertiy: far allowed you to address all of the memory, but did not allow you to create / address continuous objects (in particular, arrays) larger than one segment. This was because, when working with far pointer, the segment part of the pointer always remained unchanged when performing address arithmetic, only the 16-bit offset changed. huge pointer to the view is not different from far , but when working with the huge pointer, if necessary, both the offset and the segment are calculated. - AnT
  • one
    At the same time, by default, any modification of the huge pointer immediately caused its automatic normalization: i.e. recalculating the segment and the displacement so that the displacement is <16. Such a huge pointer, due to constant normalization, can easily "walk" throughout memory. For this you have to pay the overhead of constantly maintaining the huge pointer in a normalized form. There was also an option that said that the huge pointer should not be normalized all the time, but only when it approaches the segment boundary. It was a little more efficient, but with a number of pitfalls. - AnT