Bug 19605 – invalid forward reference error when getting the `.sizeof` of an opaque enum

Status
RESOLVED
Resolution
WORKSFORME
Severity
normal
Priority
P3
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2019-01-23T02:43:51Z
Last change time
2023-04-25T12:45:53Z
Assigned to
No Owner
Creator
elpenguino+D

Comments

Comment #0 by elpenguino+D — 2019-01-23T02:43:51Z
Very easy to reproduce: ``` enum X; static assert(X.sizeof == 0); ``` Note that I'm not exactly sure what the size of this should be. My guess was 0, but DMD 2.064 seems to manage to evaluate it to 4 despite still issuing the same error.
Comment #1 by tiberiulepadatu14 — 2019-03-07T21:40:45Z
(In reply to elpenguino+D from comment #0) > Very easy to reproduce: > ``` > enum X; > static assert(X.sizeof == 0); > ``` > > Note that I'm not exactly sure what the size of this should be. My guess was > 0, but DMD 2.064 seems to manage to evaluate it to 4 despite still issuing > the same It is 4 because it is the same as sizeof int. I will look into the error. [1] https://dlang.org/spec/enum.html
Comment #2 by dlang-bot — 2019-03-17T18:32:46Z
@Basile-z created dlang/dmd pull request #9460 "fix issue 19605 - invalid forward reference error when getting the `sizeof` of an opaque enum" fixing this issue: - fix issue 19605 - invalid forward reference error when getting the `.sizeof` of an opaque enum https://github.com/dlang/dmd/pull/9460
Comment #3 by b2.temp — 2019-03-17T19:42:20Z
This one might be invalid actually. The implementation of the fix is problematic at least.
Comment #4 by razvan.nitu1305 — 2023-04-25T09:53:07Z
sizeof is defined as being the size in bytes of an expression. It does not mean "the amount of bytes required for a variable to be stored in memory at program runtime". In this case, the compiler correctly reports that it uses 4 bytes to store the enumeration, even though it is empty. I guess this could be improved, however, that would make the code uglier. This way the compiler code treats empty enums and non-empty enums the same. The cost is that you may use some extra bytes at compile time. My take on this is that this is an invalid bug report, however, I am open to other perspectives.
Comment #5 by b2.temp — 2023-04-25T12:45:53Z
The spurious error is gone anyway.