473,321 Members | 1,667 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,321 software developers and data experts.

size of a function

does it make sense to find the size of a function ???
something like sizeof(main) ???
thanking you
ranjan.

Nov 15 '05 #1
38 2317
maadhuu wrote:
does it make sense to find the size of a function ???
something like sizeof(main) ???
thanking you
ranjan.


No, doing so is a constraint violation.

Robert Gamble

Nov 15 '05 #2
In article <f6******************************@localhost.talkab outprogramming.com>,
maadhuu <ma************@yahoo.com> wrote:
does it make sense to find the size of a function ???
something like sizeof(main) ???


No.

gcc without --pedantic allows it, but the size it returns is 1
(at least for my test cases). With --pedantic, or if I
use a stricter compiler, it complains at compile time.

Remember, there isn't anything you can -do- to a function
pointer, except to store it or call through it (or convert it
to void*). sizeof a function might make sense if you could
index the function object in some way, but you cannot
(not without invoking undefined behaviour.)

If you had hope of using a program to examine the code of
a function, or bash the function or whatnot, then you can
forget about that in standard C -- there's no portable way to do that
[and any non-portable way is a topic for a newsgroup specific to
your operating system.]
--
Any sufficiently advanced bug is indistinguishable from a feature.
-- Rich Kulawiec
Nov 15 '05 #3
maadhuu wrote on 04/09/05 :
does it make sense to find the size of a function ???
Nope.
something like sizeof(main) ???


Why do you need this information ?

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html
The C-library: http://www.dinkumware.com/refxc.html

"It's specified. But anyone who writes code like that should be
transmogrified into earthworms and fed to ducks." -- Chris Dollin CLC
Nov 15 '05 #4
i don't think there is anything wrong in knowing such things , not
necessary that it should be always used somewhere , also why is it a
violation ??

Nov 15 '05 #5
Walter Roberson wrote:
In article <f6******************************@localhost.talkab outprogramming.com>,
maadhuu <ma************@yahoo.com> wrote:
does it make sense to find the size of a function ???
something like sizeof(main) ???


No.

gcc without --pedantic allows it, but the size it returns is 1
(at least for my test cases). With --pedantic, or if I
use a stricter compiler, it complains at compile time.

Remember, there isn't anything you can -do- to a function
pointer, except to store it or call through it (or convert it
to void*).


Just to clarify: you *can* use sizeof on a function pointer, just not
on the function itself.

Robert Gamble

Nov 15 '05 #6
Please provide context when posting a followup so we know what you are
responding to.

maadhuu wrote:
i don't think there is anything wrong in knowing such things , not
necessary that it should be always used somewhere,
Agreed, if you don't ask you might never know.
also why is it a violation ??


Because the Standard says so.

Robert Gamble

Nov 15 '05 #7
"maadhuu" <ma************@yahoo.com> wrote in message
news:f6******************************@localhost.ta lkaboutprogramming.com...
does it make sense to find the size of a function ???
something like sizeof(main) ???


void myfunc(){/*body of the func whose size you want*/}
void bar(){}
bar-myfunc may tell you the size.
But it *may not* just as well due to optimizations and code reordering. I'd
not rely on this, there's no any guarantee here.

Alex
Nov 15 '05 #8
ro******@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
In article
<f6******************************@localhost.talkab outprogramming.com>,
maadhuu <ma************@yahoo.com> wrote:
does it make sense to find the size of a function ???
something like sizeof(main) ???


No.

gcc without --pedantic allows it, but the size it returns is 1
(at least for my test cases). With --pedantic, or if I
use a stricter compiler, it complains at compile time.

Remember, there isn't anything you can -do- to a function
pointer, except to store it or call through it (or convert it
to void*). sizeof a function might make sense if you could
index the function object in some way, but you cannot
(not without invoking undefined behaviour.)


Correction: you can't legally convert a function pointer to void*
(though some implementations may allow it).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #9
"Alexei A. Frounze" <al*****@chat.ru> writes:
"maadhuu" <ma************@yahoo.com> wrote in message
news:f6******************************@localhost.ta lkaboutprogramming.com...
does it make sense to find the size of a function ???
something like sizeof(main) ???


void myfunc(){/*body of the func whose size you want*/}
void bar(){}
bar-myfunc may tell you the size.
But it *may not* just as well due to optimizations and code reordering. I'd
not rely on this, there's no any guarantee here.


No, the "-" operator is not defined for function pointers.

*If* an implementation allows function pointers to be converted to
char*, then

(char*)bar - (char*)myfunc

might give you something meaningful. But conversion of a function
pointer to char* isn't legal either, though some implementations may
allow it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #10
"Robert Gamble" <rg*******@gmail.com> writes:
Please provide context when posting a followup so we know what you are
responding to.

maadhuu wrote:
i don't think there is anything wrong in knowing such things , not
necessary that it should be always used somewhere,


Agreed, if you don't ask you might never know.
also why is it a violation ??


Because the Standard says so.


And why does the Standard say so? Because there's nothing meaningful
you can do with the result. It can be interesting to know how many
bytes a given function occupies, but there's really nothing you can do
with it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #11
Robert Gamble wrote:
Please provide context when posting a followup so we know what you are
responding to.

maadhuu wrote:
i don't think there is anything wrong in knowing such things , not
necessary that it should be always used somewhere,

Agreed, if you don't ask you might never know.

also why is it a violation ??

Because the Standard says so.


Robert's answer is correct, but unsatisfactory. The
obvious follow-up is "But *why* does the Standard say so?"

There's no 100% certain answer, because the Standard
stands alone as a "finished work;" it says nothing about
the work that led to the finished form. There's a non-
normative companion document called the Rationale that goes
into such matters, but it doesn't address maadhuu's question.
I mention this lack of certainty so maadhuu and others will
understand that my answer is really just speculation. With
that out of the way:

First (as Walter Roberson pointed out), there's nothing
useful to do with a function's size, assuming you could get
hold of it. You can't malloc() memory and copy a function
into (or from!) it, because functons are not data: C is
specified in such a way that it can be implemented even if
instructions and data occupy completely different address
spaces, perhaps with completely different characteristics.
Nor can you do useful arithmetic on function pointers (where
the notion of function size would lurk in the background),
because you can't make arrays of functions: functions aren't
data. Knowing a function's size doesn't enable anything useful,
while at the same time requiring an implementation to be able
to supply a size could reduce the number of machines able to
implement C. Imagine a machine with 8-bit bytes in data space
and 36-bit instructions in instruction space: what is the
`sizeof' a five-instruction function? (Do *not* answer
"Twenty-two and one-half bytes.")

(By the way, Walter suggested that it was possible to
convert a function pointer to a `void*'. I'm sure this was
just a typo for `(void*)()', because he knows better: function
pointers and data pointers need not be interconvertible,
because the things they point to need not be in any way
similar.)

Second, the very notion of "the size" of a function is
rather slippery. What if the function has been expanded in-
in five or six places? Is "the size" the total size of all
expansions? If so, it might not be a compile-time constant
if the function is inlined in different translation units.
If "the size" is the memory footprint of one expansion, which
one is it? Note that different in-line expansions may well
generate different instruction counts. What if the optimizer
intermixes the in-line expansion's instructions with those of
the caller? What if the optimizer produces some instructions
that are not strictly attributable to either the caller or
to the expanded function? What if some optimizations occur
at run-time (think "JIT compiler"), using profiling data
gathered during the run, data that might vary from one run
to the next?

Third, we've been talking about a function's memory as
being made up of instructions, but there may well be other
"non-operating" components. For example, the first word of
a VAX subroutine is not an instruction, but a data construct
describing the subroutine linkage: which registers require
saving and restoring, that sort of thing. Other machines may
use even more complicated "dope vectors" -- and if they're
large enough a compiler may well find ways to let multiple
similar functions share the same dope vector, in which case
the dope vector's memory would be attributable to *all* the
functions that share it, and not chargeable to any one of
them ...

Those are some of my notions about "Why?", but as I said
earlier they are in no way authoritative.

--
Eric Sosman
es*****@acm-dot-org.invalid
Nov 15 '05 #12
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Alexei A. Frounze" <al*****@chat.ru> writes:
void myfunc(){/*body of the func whose size you want*/}
void bar(){}
bar-myfunc may tell you the size.
But it *may not* just as well due to optimizations and code reordering. I'd not rely on this, there's no any guarantee here.


No, the "-" operator is not defined for function pointers.

*If* an implementation allows function pointers to be converted to
char*, then

(char*)bar - (char*)myfunc

might give you something meaningful. But conversion of a function
pointer to char* isn't legal either, though some implementations may
allow it.


You're right about the latter.
And I've never tried doing arithmetics on function pointers (other than
assignment and equal/unequal comparison), so the use of the minus operator
on them is missing in my experience. Usually, there's no good reason to know
the size of function in bytes (whatever byte is in the program address
space).
I can think of only one reason why the size of func may matter... Whether it
fits into a fixed number of pages on a CPU with paging. But this is normally
what OS and driver developers may only be concerned about. The rest
shouldn't.

Alex
Nov 15 '05 #13
Eric Sosman <es*****@acm-dot-org.invalid> writes:
Robert Gamble wrote:
Please provide context when posting a followup so we know what you are
responding to.
maadhuu wrote:
i don't think there is anything wrong in knowing such things , not
necessary that it should be always used somewhere, Agreed, if you don't ask you might never know.
also why is it a violation ??

Because the Standard says so.


Robert's answer is correct, but unsatisfactory. The
obvious follow-up is "But *why* does the Standard say so?"

[snip]
Second, the very notion of "the size" of a function is
rather slippery. What if the function has been expanded in-
in five or six places? Is "the size" the total size of all
expansions? If so, it might not be a compile-time constant
if the function is inlined in different translation units.
If "the size" is the memory footprint of one expansion, which
one is it? Note that different in-line expansions may well
generate different instruction counts. What if the optimizer
intermixes the in-line expansion's instructions with those of
the caller? What if the optimizer produces some instructions
that are not strictly attributable to either the caller or
to the expanded function? What if some optimizations occur
at run-time (think "JIT compiler"), using profiling data
gathered during the run, data that might vary from one run
to the next?


If it were useful to compute the size of a function, these particular
issues could be solved. We can take the address of a function, after
all. Even if the function is inlined, perhaps multiple times, the
address gives you something through which the function can be called
with arbitrary arguments.

Having said that, the other reasons why the size of a function is not
useful are perfectly valid.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #14
Eric Sosman wrote:
Robert Gamble wrote:
Please provide context when posting a followup so we know what you are
responding to.

maadhuu wrote:
i don't think there is anything wrong in knowing such things , not
necessary that it should be always used somewhere,

Agreed, if you don't ask you might never know.

also why is it a violation ??

Because the Standard says so.

Robert's answer is correct, but unsatisfactory. The
obvious follow-up is "But *why* does the Standard say so?" There's no 100% certain answer [snip] my answer is really just speculation.


So you think that speculating about the answer to a question related to
the one that was asked (for which you claim there is no definitive
answer) makes your answer any more satisfactory than mine?

Robert Gamble

Nov 15 '05 #15
In article <f6******************************@localhost.talkab outprogramming.com>,
maadhuu <ma************@yahoo.com> wrote:
does it make sense to find the size of a function ???
something like sizeof(main) ???


As others have said, the C standard does not let you do this.

If you really need to do this kind of thing, it's probably possible to
do it by use of some operating-system-specific tools for examining
object files.

-- Richard
Nov 15 '05 #16
Robert Gamble wrote:
Eric Sosman wrote:
Robert Gamble wrote:

maadhuu wrote:

also why is it a violation ??

Because the Standard says so.

Robert's answer is correct, but unsatisfactory. The
obvious follow-up is "But *why* does the Standard say so?"
[...]
my answer is really just speculation.


So you think that speculating about the answer to a question related to
the one that was asked (for which you claim there is no definitive
answer) makes your answer any more satisfactory than mine?


To someone who regards the Universe as a given, as a
set of arbitrary phenomena requiring no explanation, your
answer is, perhaps, satisfactory. Myself, I like having
the illusion that "there's method in it," I seek more
systematic connections between the phenomena, and I (with
hubris) presume to call these connections "explanations."
The explanations are never complete, are sometimes little
more than supposition, and are sometimes even untestable --
but yes, I find it more satisfactory to have them than to
do without them. More useful, too.

"Why must a string have a '\0' at the end?" Choose
between two possible answers: (1) "Because C does not keep
track of the number of data characters in a string, it
uses a distinguished `non-data' character to indicate where
the data ends," or (2) "Because the Standard says so."

Answers of type (1), it seems to me, promote
understanding. Those of type (2) favor memorization.

--
Eric Sosman
es*****@acm-dot-org.invalid
Nov 15 '05 #17
In article <2d*****************************************@comca st.com> Eric Sosman <es*****@acm-dot-org.invalid> writes:
....
You can't malloc() memory and copy a function
into (or from!) it, because functons are not data: C is
specified in such a way that it can be implemented even if
instructions and data occupy completely different address
spaces, perhaps with completely different characteristics.


Indeed, suppose the data is organised with CHAR_BIT=9, but compiled
functions use 8-bit bytes. In that case you would in general not
even get a value that as some reasonable meaning.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Nov 15 '05 #18
On Sun, 04 Sep 2005 17:01:36 +0000, Walter Roberson wrote:
In article <f6******************************@localhost.talkab outprogramming.com>,
maadhuu <ma************@yahoo.com> wrote:
does it make sense to find the size of a function ???
something like sizeof(main) ???
No.

gcc without --pedantic allows it, but the size it returns is 1
(at least for my test cases). With --pedantic, or if I
use a stricter compiler, it complains at compile time.


That's not unreasonable. Remember that sizeof's result is in units of the
type being pointed at. So if you take the difference between 2 pointers
to int, you will get a count of ints, not bytes. So takeing the difference
between 2 function pointers would at best give you a count in units of
functions. In practice however sizeof is only defined over arrays i.e.
collections of things that have the same size and doesn't make any sense
for functions.
Remember, there isn't
anything you can -do- to a function pointer,
except to store it or call through it (or convert it to void*). sizeof a
function might make sense if you could index the function object in some
way, but you cannot (not without invoking undefined behaviour.)


Function pointers can be cast to other function pointer types but they
must be cast back to the original type before the funciton is called. A
function pointer may not meaningfully be converted to any pointer to data
type, including void *.

Lawrence
Nov 15 '05 #19
Lawrence Kirby <lk****@netactive.co.uk> writes:
On Sun, 04 Sep 2005 17:01:36 +0000, Walter Roberson wrote:
In article
<f6******************************@localhost.talkab outprogramming.com>,
maadhuu <ma************@yahoo.com> wrote:
does it make sense to find the size of a function ???
something like sizeof(main) ???


No.

gcc without --pedantic allows it, but the size it returns is 1
(at least for my test cases). With --pedantic, or if I
use a stricter compiler, it complains at compile time.


That's not unreasonable. Remember that sizeof's result is in units of the
type being pointed at. So if you take the difference between 2 pointers
to int, you will get a count of ints, not bytes. So takeing the difference
between 2 function pointers would at best give you a count in units of
functions. In practice however sizeof is only defined over arrays i.e.
collections of things that have the same size and doesn't make any sense
for functions.


Um, maybe you shouldn't post before you've had your coffee? 8-)}

sizeof always yields a result in bytes. Pointer subtraction yields a
result in units of the type being pointed at. (I know you know that.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #20
Robert Gamble wrote:
Walter Roberson wrote:
In article <f6******************************@localhost.talkab outprogramming.com>,
maadhuu <ma************@yahoo.com> wrote:
does it make sense to find the size of a function ???
something like sizeof(main) ???


No.

gcc without --pedantic allows it, but the size it returns is 1
(at least for my test cases). With --pedantic, or if I
use a stricter compiler, it complains at compile time.

Remember, there isn't anything you can -do- to a function
pointer, except to store it or call through it (or convert it
to void*).

Just to clarify: you *can* use sizeof on a function pointer, just not
on the function itself.

Robert Gamble

Really? Given 'int foo(int);' somewhere the compiler will see 'foo' as
the address of a function. There is no information anywhere as to how
many bytes of memory are required to house foo().

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 15 '05 #21
Joe Wright <jw*****@comcast.net> writes:
Robert Gamble wrote:

[...]
Just to clarify: you *can* use sizeof on a function pointer, just not
on the function itself.
Robert Gamble

Really? Given 'int foo(int);' somewhere the compiler will see 'foo' as
the address of a function. There is no information anywhere as to how
many bytes of memory are required to house foo().


Yes, really, you can apply sizeof to a function pointer. The result
is the size of the pointer, not the size of the function.

Note that "sizeof foo" won't do this, since the argument to sizeof is
one of the contexts in which a function name is *not* implicitly
converted to a pointer.

For example:

#include <stdio.h>

int foo(int i)
{
}

int main(void)
{
int (*foo_ptr)(int) = foo;
printf("sizeof foo_ptr = %d\n", (int)sizeof foo_ptr);
return 0;
}

On one implementation I tried, this prints
sizeof foo_ptr = 4

On another, it prints
sizeof foo_ptr = 8

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #22
Joe Wright wrote:
Robert Gamble wrote:
Walter Roberson wrote:
In article <f6******************************@localhost.talkab outprogramming.com>,
maadhuu <ma************@yahoo.com> wrote:

does it make sense to find the size of a function ???
something like sizeof(main) ???

No.

gcc without --pedantic allows it, but the size it returns is 1
(at least for my test cases). With --pedantic, or if I
use a stricter compiler, it complains at compile time.

Remember, there isn't anything you can -do- to a function
pointer, except to store it or call through it (or convert it
to void*).

Just to clarify: you *can* use sizeof on a function pointer, just not
on the function itself.

Robert Gamble

Really? Given 'int foo(int);' somewhere the compiler will see 'foo' as
the address of a function. There is no information anywhere as to how
many bytes of memory are required to house foo().


foo is of type function, it is not a function pointer.

Robert Gamble

Nov 15 '05 #23
Keith Thompson wrote:
Eric Sosman <es*****@acm-dot-org.invalid> writes:
[ snip ]
If it were useful to compute the size of a function, these particular
issues could be solved. We can take the address of a function, after
all. Even if the function is inlined, perhaps multiple times, the
address gives you something through which the function can be called
with arbitrary arguments.

Having said that, the other reasons why the size of a function is not
useful are perfectly valid.


I asked my gcc implementation about the size of main.

#include <stdio.h>
int main(void) {
printf("The size of main seems to be %d.\n",
(int)sizeof main);
return 0;
}

The size of main seems to be 1.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 15 '05 #24
Joe Wright <jw*****@comcast.net> writes:
Keith Thompson wrote:
Eric Sosman <es*****@acm-dot-org.invalid> writes:

[ snip ]
If it were useful to compute the size of a function, these particular
issues could be solved. We can take the address of a function, after
all. Even if the function is inlined, perhaps multiple times, the
address gives you something through which the function can be called
with arbitrary arguments.
Having said that, the other reasons why the size of a function is not
useful are perfectly valid.


I asked my gcc implementation about the size of main.

#include <stdio.h>
int main(void) {
printf("The size of main seems to be %d.\n",
(int)sizeof main);
return 0;
}

The size of main seems to be 1.


Here's what the gcc documentation says about this:

In GNU C, addition and subtraction operations are supported on
pointers to `void' and on pointers to functions. This is done by
treating the size of a `void' or of a function as 1.

A consequence of this is that `sizeof' is also allowed on
`void' and on function types, and returns 1.

The option `-Wpointer-arith' requests a warning if these
extensions are used.

I can understand the idea of allowing pointer arithmetic on void*
(though I think it's a bad idea), but it's difficult to think of a
good use for pointer arithmetic on function pointers.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #25
"Dik T. Winter" <Di********@cwi.nl> wrote in message
news:IM********@cwi.nl...
In article <2d*****************************************@comca st.com> Eric Sosman <es*****@acm-dot-org.invalid> writes: ...
> You can't malloc() memory and copy a function
> into (or from!) it, because functons are not data: C is
> specified in such a way that it can be implemented even if
> instructions and data occupy completely different address
> spaces, perhaps with completely different characteristics.


Indeed, suppose the data is organised with CHAR_BIT=9, but compiled
functions use 8-bit bytes. In that case you would in general not
even get a value that as some reasonable meaning.


Actually, since void* and void(*)() are different types of pointers and in
general point to different address spaces (data and code, respectively),
it's fine to calculate difference of function pointers and get the distance
between the two in whatever the minimal addressable unit (MAU) is in the
program address space, similarly to data pointers and data space. That's
just fine. I know a platform where data space MAU is 16-bit long and program
space MAU is 8-bit long. It would be OK to get the appropriate amount of
MAUs in their respective address spaces. And data MAU not necessarily needs
to equal to program MAU... That's the user's problem if they use data MAUs
for program and vice versa, just like using void* in place of void(*)().

Alex
Nov 15 '05 #26
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
....
I can understand the idea of allowing pointer arithmetic on void*
(though I think it's a bad idea), but it's difficult to think of a
good use for pointer arithmetic on function pointers.


Poking/patching/modifying the program on the fly by writing program space
MAUs to program memory using function pointers...

E.g.:

void MyBrokenFxn()
{
//...
}

ProgMAU aNewCode[] = {0xC3/*ret*/};

void (*p)() = &MyBrokenFxn;

int i;
for (i=0; i<sizeof(ProgMAU)/sizeof(ProgMAU[0]); i++)
p[i] = aNewCode[i];
Btw, any decent general purpose OS must be able to load programs (I, stress,
the code) to program memory. Even if we leave along all those protection
mechanisms and other CPU/OS-specific things that are due, the sole process
of modifying program memory is implementation specific in C because C
doesn't support this thing in general (unless the program and data memories
are the same thing or are somehow mapped into each other). Don't you find
this funny about C and Unix? Unix was written mostly in C but at the same
time there was no support for this regular operation (modifying program
memory) in C :)
This was left to the ASM...

Alex
Nov 15 '05 #27
"Alexei A. Frounze" <al*****@chat.ru> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
...
I can understand the idea of allowing pointer arithmetic on void*
(though I think it's a bad idea), but it's difficult to think of a
good use for pointer arithmetic on function pointers.
Poking/patching/modifying the program on the fly by writing program space
MAUs to program memory using function pointers...

E.g.:

void MyBrokenFxn()
{
//...
}

ProgMAU aNewCode[] = {0xC3/*ret*/};

void (*p)() = &MyBrokenFxn;

int i;
for (i=0; i<sizeof(ProgMAU)/sizeof(ProgMAU[0]); i++)
p[i] = aNewCode[i];


You have a type conflict in the assignment. p is a
pointer-to-function, so p[i] would be of a function type; presumably
even gcc won't let you assign to that.

On platforms where it makes sense, you can always convert between
pointer-to-function and, say, unsigned char* (which is, strictly
speaking, a constraint violation, but a reasonable extension).

If you're going to read or write values through the pointer, you're
going to have to convert it to an object pointer type anyway.
Btw, any decent general purpose OS must be able to load programs (I, stress,
the code) to program memory. Even if we leave along all those protection
mechanisms and other CPU/OS-specific things that are due, the sole process
of modifying program memory is implementation specific in C because C
doesn't support this thing in general (unless the program and data memories
are the same thing or are somehow mapped into each other). Don't you find
this funny about C and Unix? Unix was written mostly in C but at the same
time there was no support for this regular operation (modifying program
memory) in C :)
This was left to the ASM...


There's no reason you can't do that kind of thing in C (though not in
portable C). Any such code will almost inevitably invoke undefined
behavior, but OS code is allowed to do that. (I suppose I'm assuming
that code and data are in the same address space; if they aren't, the
implementation can provide extensions.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #28
Lawrence Kirby <lk****@netactive.co.uk> writes:
Function pointers can be cast to other function pointer types but they
must be cast back to the original type before the funciton is called.


Probably it's true that function pointers must be converted just to a
type that is compatible with the type of the function being called,
not necessarily the exact type of the function. This guarantee is
not stated explicitly, but it is implied: 6.3.2.3 p8, 6.5.2.2 p9.

[Note: glossing over the distinction between a function type and
a type that is a pointer to said function type, which the language
rules make rather easy to do.]
Nov 15 '05 #29
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
Eric Sosman <es*****@acm-dot-org.invalid> writes:
Robert Gamble wrote:
Please provide context when posting a followup so we know what you are responding to.
maadhuu wrote:

i don't think there is anything wrong in knowing such things , not
necessary that it should be always used somewhere,
Agreed, if you don't ask you might never know.

also why is it a violation ??
Because the Standard says so.


Robert's answer is correct, but unsatisfactory. The
obvious follow-up is "But *why* does the Standard say so?"

[snip]
Second, the very notion of "the size" of a function is
rather slippery. What if the function has been expanded in-
in five or six places? Is "the size" the total size of all
expansions? If so, it might not be a compile-time constant
if the function is inlined in different translation units.
If "the size" is the memory footprint of one expansion, which
one is it? Note that different in-line expansions may well
generate different instruction counts. What if the optimizer
intermixes the in-line expansion's instructions with those of
the caller? What if the optimizer produces some instructions
that are not strictly attributable to either the caller or
to the expanded function? What if some optimizations occur
at run-time (think "JIT compiler"), using profiling data
gathered during the run, data that might vary from one run
to the next?


If it were useful to compute the size of a function, these particular
issues could be solved. We can take the address of a function, after
all. Even if the function is inlined, perhaps multiple times, the
address gives you something through which the function can be called
with arbitrary arguments.

Having said that, the other reasons why the size of a function is not
useful are perfectly valid.


We agree so often that you only rarely have to deal with my nonsense,
but I think we can both appreciate that code-bloat can be a problem in
many companies.

In fact I remember a story from back when MicroSoft (capital S) was
attempting to work with IBM and their progress was counted by LOC
measurement. MS had a problem with this, since they preferred
streamlining code to filling up code with arbitrary bloat by whatever
methods they could find (I could mention some, like extraneous comments,
multi-lining code that could be written more concisely, etc - but I
WON'T!)

I believe that there is a VALID reason to have SOF verification!

This is not just a programmer problem, or a program fault; managers need
to be held accountable, as well as companies. It takes a company to
create a program, never forget! Most people, many of them managers, that
I have "spoken" to have agreed that SOF verification does not even go
far, enough!

A company shouldn't have a posse of unused subroutines floating around
without proper version control, spawning random unused processes at
will!

Perhaps a hacker-after program that can eliminate the bloat several
months after it "shows" is
acceptable to some, but not to me! A more bloat-aware metric needs to be
perfected! Why is it always the program's fault, and never the
progRAMer. Why can't there be some kind of "after-bloat check" that the
program could have access to?! Is it because the program is a beta?! We
need to understand that beta program bloat is not a shameful NOR
uncommon occurrence! Many programs spawn processes in their beta stage.
It is just a fact, and managers just need to come online and deal with
it. If we don't deal with beta code-bloat, at the alpha site, then we
will propagate early release without a doubt!

There are many problems our companies sweep into the bit-bucket, but the
time has come to address these issues!

--
Mabden
Nov 15 '05 #30
On Mon, 05 Sep 2005 17:50:02 +0000, Keith Thompson wrote:

....
That's not unreasonable. Remember that sizeof's result is in units of the
type being pointed at. So if you take the difference between 2 pointers
to int, you will get a count of ints, not bytes. So takeing the difference
between 2 function pointers would at best give you a count in units of
functions. In practice however sizeof is only defined over arrays i.e.
collections of things that have the same size and doesn't make any sense
for functions.


Um, maybe you shouldn't post before you've had your coffee? 8-)}

sizeof always yields a result in bytes. Pointer subtraction yields a
result in units of the type being pointed at. (I know you know that.)


Thank you, I meant pointer difference. I'm not sure how it turned into
sizeof. :-)

Lawrence

Nov 15 '05 #31
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...
"Alexei A. Frounze" <al*****@chat.ru> writes: ....
ProgMAU aNewCode[] = {0xC3/*ret*/};

void (*p)() = &MyBrokenFxn;

int i;
for (i=0; i<sizeof(ProgMAU)/sizeof(ProgMAU[0]); i++)
p[i] = aNewCode[i];


You have a type conflict in the assignment. p is a
pointer-to-function, so p[i] would be of a function type; presumably
even gcc won't let you assign to that.

On platforms where it makes sense, you can always convert between
pointer-to-function and, say, unsigned char* (which is, strictly
speaking, a constraint violation, but a reasonable extension).


Indeed, p is pointer to function...

What's interesting, gcc compiles the following on x86:
void (*p)()=(void(*)())1;
printf ("%lu\n", (unsigned long)(p+1));
and the printf prints 2. It's not assigning to *(char*)p, but at least 1 can
be added to p as I might expect it.

Actually, even the following compiles with gcc (with -Wall) and gives 10:
void (*p)()=(void(*)())1;
void (*q)()=(void(*)())11;
printf ("%lu\n", (unsigned long)(q-p));

So, is it that gcc supports some function pointer arithmetics?

And the more interesting thing is that the following two lines result in
different errors:
p[1] = 0; // error: subscripted value is neither array nor pointer
*(p+1) = 0; // error: invalid lvalue in assignment
First says what it says about p (though p *is* a pointer, albeit not pointer
to data) while second says *(p+1) is bad lvalue (the same error is issued
for *p = 0; too).
Quite odd that p[1] and *(p+1) are treated differently.
If you're going to read or write values through the pointer, you're
going to have to convert it to an object pointer type anyway.


Right.
Btw, any decent general purpose OS must be able to load programs (I, stress, the code) to program memory. Even if we leave along all those protection
mechanisms and other CPU/OS-specific things that are due, the sole process of modifying program memory is implementation specific in C because C
doesn't support this thing in general (unless the program and data memories are the same thing or are somehow mapped into each other). Don't you find this funny about C and Unix? Unix was written mostly in C but at the same time there was no support for this regular operation (modifying program
memory) in C :)
This was left to the ASM...


There's no reason you can't do that kind of thing in C (though not in
portable C). Any such code will almost inevitably invoke undefined
behavior, but OS code is allowed to do that. (I suppose I'm assuming
that code and data are in the same address space; if they aren't, the
implementation can provide extensions.)


That's the point.

Alex
Nov 15 '05 #32
"Mabden" <mabden@sbc_global.net> writes:
"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

[...]
Having said that, the other reasons why the size of a function is not
useful are perfectly valid.

We agree so often that you only rarely have to deal with my nonsense,
but I think we can both appreciate that code-bloat can be a problem in
many companies.

[snip]

I didn't want to quote everything you wrote. To summarize, you argue
that it's useful to know the size of a function, to measure and avoid
code bloat.

I actually agree, but I think the right way to do that is to use
external tools that examine object files and/or executables.

Knowing the code size of a function can be useful, but I don't see how
it can be useful to compute it within the program. Any code that
computes and checks this would only *add* to code bloat. It also
can't easily iterate over all the functions in the program; there's no
way for a program that uses a given library to know all the functions
(visible or not) that make up the library. An external tool can
easily do all of this.

I'm not sure how useful this is, but to the extent that it's useful it
should be done by external tools.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #33
Keith Thompson wrote:
[...]
I didn't want to quote everything you wrote. To summarize, you argue
that it's useful to know the size of a function, to measure and avoid
code bloat.

I actually agree, but I think the right way to do that is to use
external tools that examine object files and/or executables.

Knowing the code size of a function can be useful, but I don't see how
it can be useful to compute it within the program. Any code that
computes and checks this would only *add* to code bloat. It also
can't easily iterate over all the functions in the program; there's no
way for a program that uses a given library to know all the functions
(visible or not) that make up the library. An external tool can
easily do all of this.

[...]

Also, given optimizers, it may not be possible to give you the size of
a function. I have seen compilers generate code which was shared by
more than one function, when those functions ended the same way.

For example:

int foo()
{
int i,j;
... lots of code
for ( i=0, j=0 ; i < 10 ; i++ )
j += foobar(i);
return(j);
}

int bar()
{
int i,j;
... lots of code, but different than foo()
for ( i=0, j=0 ; i < 10 ; i++ )
j += foobar(i);
return(j);
}

The end of bar() would not include the for loop, the calls to foobar(),
or the return. Rather, there would be a JMP to the code within foo().

Would you consider that shared machine code part of bar()? If not, would
you consider foo() "bloated" because it was that much larger than bar()?

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

Nov 15 '05 #34
Keith Thompson wrote:
Joe Wright <jw*****@comcast.net> writes:
Robert Gamble wrote:


[...]
Just to clarify: you *can* use sizeof on a function pointer, just not
on the function itself.
Robert Gamble


Really? Given 'int foo(int);' somewhere the compiler will see 'foo' as
the address of a function. There is no information anywhere as to how
many bytes of memory are required to house foo().

Yes, really, you can apply sizeof to a function pointer. The result
is the size of the pointer, not the size of the function.

Note that "sizeof foo" won't do this, since the argument to sizeof is
one of the contexts in which a function name is *not* implicitly
converted to a pointer.

For example:

#include <stdio.h>

int foo(int i)
{
}

int main(void)
{
int (*foo_ptr)(int) = foo;
printf("sizeof foo_ptr = %d\n", (int)sizeof foo_ptr);
return 0;
}

On one implementation I tried, this prints
sizeof foo_ptr = 4

On another, it prints
sizeof foo_ptr = 8


#include <stdio.h>

int foo(void) {
return 0;
}

int main(void)
{
printf("sizeof foo is %d bytes.\n", (int)sizeof foo);
printf("sizeof printf is %d bytes.\n", (int)sizeof printf);
return 0;
}

At my house, gcc 3.1 prints 1 in both cases.

We agree that the sizeof a pointer is whatever the size of a pointer is.
My point is that the size of a function is not available. The compiler
cannot know it.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 15 '05 #35
Joe Wright <jw*****@comcast.net> writes:
Keith Thompson wrote:
Joe Wright <jw*****@comcast.net> writes:
Robert Gamble wrote: [...]
Just to clarify: you *can* use sizeof on a function pointer, just not
on the function itself.
Robert Gamble
Really? Given 'int foo(int);' somewhere the compiler will see 'foo' as
the address of a function. There is no information anywhere as to how
many bytes of memory are required to house foo().

Yes, really, you can apply sizeof to a function pointer. The result
is the size of the pointer, not the size of the function.
Note that "sizeof foo" won't do this, since the argument to sizeof is
one of the contexts in which a function name is *not* implicitly
converted to a pointer.
For example:
#include <stdio.h>
int foo(int i)
{
}
int main(void)
{
int (*foo_ptr)(int) = foo;
printf("sizeof foo_ptr = %d\n", (int)sizeof foo_ptr);
return 0;
}
On one implementation I tried, this prints
sizeof foo_ptr = 4
On another, it prints
sizeof foo_ptr = 8


#include <stdio.h>

int foo(void) {
return 0;
}

int main(void)
{
printf("sizeof foo is %d bytes.\n", (int)sizeof foo);
printf("sizeof printf is %d bytes.\n", (int)sizeof printf);
return 0;
}

At my house, gcc 3.1 prints 1 in both cases.


Yes, I get the same result. With "-pedantic", I also get:

tmp.c:9: warning: invalid application of `sizeof' to a function type
tmp.c:10: warning: invalid application of `sizeof' to a function type
We agree that the sizeof a pointer is whatever the size of a pointer
is. My point is that the size of a function is not available. The
compiler cannot know it.


Right, none of this is in dispute.

Looking at the quoted text above, Robert Gamble wrote:

Just to clarify: you *can* use sizeof on a function pointer, just not
on the function itself.

You replied:

Really?
[...]

And I replied:

Yes, really, you can apply sizeof to a function pointer.
[...]

Perhaps you thought that Robert Gamble was saying that applying sizeof
to a function pointer would give you the size of the function. I
don't believe that's what he meant.

If that wasn't the source of the confusion, what exactly did you mean
by your "Really?" above? You seemed to be questioning Robert's
statements, which were perfectly correct.

To summarize:

You cannot determine the size of a function in (unextended) C.

You can determine the size of a function pointer; this is not relevant
to the size of the function itself.

Applying the sizeof operator to a function name is a constraint
violation. The function name is not implicitly converted to a pointer
as it is in most other contexts.

(gcc, as an extension, yields a meaningless value of 1 when the sizeof
operator is applied to a function name. This is a side effect of its
(arguably ill-advised) support of pointer arithmetic on function
pointers. This is entireliy non-standard, though gcc is permitted to
do this as long as it issues a diagnostic in conforming mode.)

I don't recall seeing any statements in this thread that contradict
any of this.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 15 '05 #36
Joe Wright <jw*****@comcast.net> writes:
We agree that the sizeof a pointer is whatever the size of a pointer is.
My point is that the size of a function is not available. The compiler
cannot know it.


Mostly I've been just skimming the articles in this thread.
However, I had a humorous thought. (Incidentally, it goes
along nicely with Joe's comment, so I'm putting it here.)
Consider "the usual idiom" applied in this discussion:

int
main( void ){
int (*p)(void);

/* get space for 10 functions */
p = malloc( 10 * sizeof *p );

return 0;
}

Needless to say, the code here is nonsensical as C is now.
The sizeof operator doesn't give the size of a variable; it
gives the size of a type -- either the type that is the
operand, or the type of the operand expression. The "size"
of the code that makes up a function can't be determined
based on its type.

So don't any of y'all be a askin for sizeof to work with
function types. :)
Nov 15 '05 #37
Keith Thompson wrote:
Joe Wright <jw*****@comcast.net> writes:
Keith Thompson wrote:
Joe Wright <jw*****@comcast.net> writes:
Robert Gamble wrote:

[...]
>Just to clarify: you *can* use sizeof on a function pointer, just not
>on the function itself.
>Robert Gamble
>

Really? Given 'int foo(int);' somewhere the compiler will see 'foo' as
the address of a function. There is no information anywhere as to how
many bytes of memory are required to house foo().

Yes, really, you can apply sizeof to a function pointer. The result
is the size of the pointer, not the size of the function.
Note that "sizeof foo" won't do this, since the argument to sizeof is
one of the contexts in which a function name is *not* implicitly
converted to a pointer.
For example:
#include <stdio.h>
int foo(int i)
{
}
int main(void)
{
int (*foo_ptr)(int) = foo;
printf("sizeof foo_ptr = %d\n", (int)sizeof foo_ptr);
return 0;
}
On one implementation I tried, this prints
sizeof foo_ptr = 4
On another, it prints
sizeof foo_ptr = 8


#include <stdio.h>

int foo(void) {
return 0;
}

int main(void)
{
printf("sizeof foo is %d bytes.\n", (int)sizeof foo);
printf("sizeof printf is %d bytes.\n", (int)sizeof printf);
return 0;
}

At my house, gcc 3.1 prints 1 in both cases.

Yes, I get the same result. With "-pedantic", I also get:

tmp.c:9: warning: invalid application of `sizeof' to a function type
tmp.c:10: warning: invalid application of `sizeof' to a function type

We agree that the sizeof a pointer is whatever the size of a pointer
is. My point is that the size of a function is not available. The
compiler cannot know it.

Right, none of this is in dispute.

Looking at the quoted text above, Robert Gamble wrote:

Just to clarify: you *can* use sizeof on a function pointer, just not
on the function itself.

You replied:

Really?
[...]

And I replied:

Yes, really, you can apply sizeof to a function pointer.
[...]

Perhaps you thought that Robert Gamble was saying that applying sizeof
to a function pointer would give you the size of the function. I
don't believe that's what he meant.

If that wasn't the source of the confusion, what exactly did you mean
by your "Really?" above? You seemed to be questioning Robert's
statements, which were perfectly correct.

To summarize:

You cannot determine the size of a function in (unextended) C.

You can determine the size of a function pointer; this is not relevant
to the size of the function itself.

Applying the sizeof operator to a function name is a constraint
violation. The function name is not implicitly converted to a pointer
as it is in most other contexts.

(gcc, as an extension, yields a meaningless value of 1 when the sizeof
operator is applied to a function name. This is a side effect of its
(arguably ill-advised) support of pointer arithmetic on function
pointers. This is entireliy non-standard, though gcc is permitted to
do this as long as it issues a diagnostic in conforming mode.)

I don't recall seeing any statements in this thread that contradict
any of this.

You're quite right. I don't know how I got it turned around but I
thought it was being argued that 'sizeof main' would give something
useful. Sorry for adding only noise.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Nov 15 '05 #38
Keith Thompson wrote:

Eric Sosman <es*****@acm-dot-org.invalid> writes:
Robert Gamble wrote:
maadhuu wrote:

i don't think there is anything wrong in knowing such things , not
necessary that it should be always used somewhere,
Agreed, if you don't ask you might never know.

also why is it a violation ??
Because the Standard says so.


Robert's answer is correct, but unsatisfactory. The
obvious follow-up is "But *why* does the Standard say so?"

[snip]
Second, the very notion of "the size" of a function is
rather slippery. What if the function has been expanded in-
in five or six places? Is "the size" the total size of all
expansions? If so, it might not be a compile-time constant
if the function is inlined in different translation units.
If "the size" is the memory footprint of one expansion, which
one is it? Note that different in-line expansions may well
generate different instruction counts. What if the optimizer
intermixes the in-line expansion's instructions with those of
the caller? What if the optimizer produces some instructions
that are not strictly attributable to either the caller or
to the expanded function? What if some optimizations occur
at run-time (think "JIT compiler"), using profiling data
gathered during the run, data that might vary from one run
to the next?


If it were useful to compute the size of a function, these particular
issues could be solved. We can take the address of a function, after
all. Even if the function is inlined, perhaps multiple times, the
address gives you something through which the function can be called
with arbitrary arguments.

Having said that, the other reasons why the size of a function is not
useful are perfectly valid.


The size of a function is truly meaningless
under the current rules of C.
Functions are not required to be composed of contiguous bytes,
like objects. Functions may share commmon parts.

Should sizeof yield a big number or a small number,
to describe a Standard Library function
which only consisted of a few instructions,
but which called functions
which consisted of a large number of instructions?

--
pete
Nov 15 '05 #39

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

25
by: Matthias | last post by:
Hi, I am just reading that book by Scott Meyers. In Item 4 Meyers suggests to always use empty() instead of size() when probing for emptyness of STL containers. His reasoning is that size()...
1
by: Timo | last post by:
All my font-sizes are set as relative sizes in CSS (large, medium, small, x-small, etc). Let's say something is set in CSS to be xx-large, but a visually impaired user wants it displayed even...
18
by: bsder | last post by:
Hi, Can anyone please tell me how to calculate the size of the following 4-dimensional array, and now to use qsort for sorting on this array? double sp = { 4.0, 5.0, 6.0 }; double spa = { {...
20
by: tigrfire | last post by:
I need the following code to return a string of character stored in array and also return the size of the array. I want to do it without using pointers and so far have the character storing working...
4
by: tshad | last post by:
I am having trouble with links in my DataGrid. I have Links all over my page set to smaller and they are consistant all over the page in both Mozilla and IE, except for the DataGrid. Here is a...
2
by: yxq | last post by:
Hello I want to get Windows clipboard data size, seem to use the function "GetClipboardDataSize". Could anyone please tell how to do using vb.net? Thanks
7
by: bowlderster | last post by:
Hello,all. I want to get the array size in a function, and the array is an argument of the function. I try the following code. /*************************************** */ #include<stdio.h>...
1
by: chrisj | last post by:
I'm using freeASPupload and got some assistance integrating to a Member script. It works successfully. In this modified version there are two groups that use this upload script. Members of one...
6
by: Marcolino | last post by:
Hi all, I have a simple problem but I don't know which is the best way to solve it. I need to savo into a table into access DB the location and the size of a form. Is there a way to save...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: CloudSolutions | last post by:
Introduction: For many beginners and individual users, requiring a credit card and email registration may pose a barrier when starting to use cloud servers. However, some cloud server providers now...
1
by: Shællîpôpï 09 | last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome former...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.