search for: field_siz

I noticed a problem with handling UIDL msgnumber in test46. If you do "UIDL 1" on a POP3 connection it returns the UID of the message followed by a dot and an error message. I made 2 changes: I added the following line to line 527 of src/pop3/commands.c ctx->message = message; I changed line 559 from: if (list_uids_iter(client, ctx)) to: if (!list_uids_iter(client, ctx))

It's hard to say. What you've described sounds close to a neutral type system implemented in metadata. In particular, ". It also defines a set of language-neutral formal rules that LLVM codegen follows to determine whether a given pair of accesses are allowed to overlap by rules of the input language. " and "the base type followed by field descriptors" etc Despite the

...ther a terminal access node that refers to > the corresponding access type: > !5 = !{ !1 } > !9 = !{ !3 } > > or a member node that refers to a structure/class or union field > descriptor and a subsequent access path node: > !7 = !{ !type_group, !field_id, !field_offset, !field_size } > !11 = !{ !5, !9, !7 } > > For a field node the first element refers to its type. The > purpose of other elements is to make the field node unique. Their > meaning is unspecified. Currently the other members for C and C++ > are the field name, bit offset and bit size of the...

...that refers to >> the corresponding access type: >> !5 = !{ !1 } >> !9 = !{ !3 } >> >> or a member node that refers to a structure/class or union field >> descriptor and a subsequent access path node: >> !7 = !{ !type_group, !field_id, !field_offset, !field_size } >> !11 = !{ !5, !9, !7 } >> >> For a field node the first element refers to its type. The >> purpose of other elements is to make the field node unique. Their >> meaning is unspecified. Currently the other members for C and C++ >> are the field name, bit off...

...me. I wrote a small program to print the structure layout of the following and compiled it with both Clang and GCC. struct S { pthread_mutex_t mutex; pthread_cond_t cond; int32_t int32_1; int32_t int32_2; }; The output are as following (the format is: field_address (+offset): field_name; field_size): gcc 0xbe92d588 (+0) : mutex ; 24 0xbe92d5a0 (+24): cond ; 48 0xbe92d5d0 (+72): int32_1 ; 4 0xbe92d5d4 (+76): int32_2 ; 4 clang 0xbe856580 (+0) : mutex ; 24 0xbe856598 (+24): cond ; 48 0xbe8565d0 (+80): int32_1 ; 4 0xbe8565d4 (+84): int32_2 ; 4 I don't understand the way how Clang alig...

...mes; p != end && *p != '\0'; p++) ; (gdb) bt full #0 0x00007fca22f0ca85 in mail_cache_header_fields_read (cache=cache at entry=0x7fca24a04f70) at mail-cache-fields.c:369 field_hdr = 0x7fca21d37010 field = {name = 0x0, idx = 0, type = MAIL_CACHE_FIELD_FIXED_SIZE, field_size = 0, decision = MAIL_CACHE_DECISION_NO, last_used = 0} last_used = 0x7fca21d3701c sizes = 0x7fca79d3701c types = 0x7fcad1d3701c <Address 0x7fcad1d3701c out of bounds> decisions = 0x7fcae7d3701c <Address 0x7fcae7d3701c out of bounds>...

...ther a terminal access node that refers to > the corresponding access type: > !5 = !{ !1 } > !9 = !{ !3 } > > or a member node that refers to a structure/class or union field > descriptor and a subsequent access path node: > !7 = !{ !type_group, !field_id, !field_offset, !field_size } > !11 = !{ !5, !9, !7 } > > For a field node the first element refers to its type. The > purpose of other elements is to make the field node unique. Their > meaning is unspecified. Currently the other members for C and C++ > are the field name, bit offset and bit size of the...

...at = UID%u-%v } ------------------------------------------------------- (gdb) bt full #0 0x00007f351537e9cd in mail_cache_header_fields_read (cache=0xf16740) at mail-cache-fields.c:369 field_hdr = 0x7f35157ed040 field = {name = 0x0, idx = 0, type = MAIL_CACHE_FIELD_FIXED_SIZE, field_size = 0, decision = MAIL_CACHE_DECISION_NO, last_used = 0} last_used = 0x7f35157ed04c sizes = 0x7f35217ed04c types = 0x7f352d7ed04c <Address 0x7f352d7ed04c out of bounds> decisions = 0x7f35307ed04c <Address 0x7f35307ed04c out of bounds> p = 0x7...

We uograded our dovecot from version 2.1.10 -> 2.10.12, but within the first hour of use, dovecot-lda would segfault during delivery. This left a lock file lying around causing the user's mail readers to hang; much hilarity ensues. All further deliveries to the same user will result in a crash. The only thing that fixes this condition is to blow away the user's INBOX cache index.